Simple Path Control Protocol Specification

Network Working Group                                       D. Lillethun
Internet-Draft                                                  J. Lange
Expires: 20 August 2006                                    J. Weinberger
                                                                   iCAIR
                                                        20 February 2006

               Simple Path Control Protocol Specification
                  draft-lillethun-spc-protocol-01.txt

Status of This Memo

   By submitting this Internet-Draft, each author represents that
   any applicable patent or other IPR claims of which he or she is
   aware have been or will be disclosed, and any of which he or she
   becomes aware will be disclosed, in accordance with Section 6 of
   BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than a "work in progress."

   The list of current Internet-Drafts can be accessed at:
   http://www.ietf.org/lid-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at:
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on April 22, 2006.
   Distribution of this memo is unlimited. Comments should be submitted
   to Dave Lillethun at davel@alumni.northwestern.edu.

Copyright Notice

   Copyright (C) The Internet Socient (2006). All Rights Reserved.

Abstract

   The Simple Path Control Protocol (SPC) defined in this document is a
   new protocol defined to enable processes external to networks to
   establish, delete and monitor paths, including lightpaths. The
   architecture of this protocol establishes a method of providing
   messages, and procedures that allow such external processes to
   use those messages to directly request network resources related to
   path provisioning.







Lillethun, Lange, Weinberger     Expires August 20, 2006       [Page  1]

Internet-Draft  Simple Path Control Protocol Specification February 2006

Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Definitions  . . . . . . . . . . . . . . . . . . . . . . .  3
   3.    Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.1    Request-Response Interaction  . . . . . . . . . . . . . .  4
   3.2    Typical Session . . . . . . . . . . . . . . . . . . . . .  4
   3.3    Type-Length-Value Encoding  . . . . . . . . . . . . . . .  5
   4.    SPC Requests . . . . . . . . . . . . . . . . . . . . . . .  5
   4.1    Message Header  . . . . . . . . . . . . . . . . . . . . .  5
   4.2    Keepalive Message . . . . . . . . . . . . . . . . . . . .  5
   4.3    Quit Message  . . . . . . . . . . . . . . . . . . . . . .  5
   4.4    Find Path Message . . . . . . . . . . . . . . . . . . . .  5
   4.5    Create Path Message . . . . . . . . . . . . . . . . . . .  6
   4.6    Find and Create Path Message  . . . . . . . . . . . . . .  6
   4.7    Teardown Path Message . . . . . . . . . . . . . . . . . .  6
   4.8    Path Info Request . . . . . . . . . . . . . . . . . . . .  6
   5.    SPC Message Encodings  . . . . . . . . . . . . . . . . . .  6
   5.1    Message Header  . . . . . . . . . . . . . . . . . . . . .  7
   5.2    Keepalive Message . . . . . . . . . . . . . . . . . . . .  8
   5.3    Quit Message  . . . . . . . . . . . . . . . . . . . . . .  8
   5.4    Find Path Message . . . . . . . . . . . . . . . . . . . .  8
   5.5    Find Path Result Message  . . . . . . . . . . . . . . . . 10
   5.5.1   Path . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.6    Create Path Message . . . . . . . . . . . . . . . . . . . 11
   5.7    Create Path Result Message  . . . . . . . . . . . . . . . 11
   5.8    Find and Create Path Message  . . . . . . . . . . . . . . 12
   5.9    Teardown Path Message . . . . . . . . . . . . . . . . . . 14
   5.10   Result Messsage . . . . . . . . . . . . . . . . . . . . . 14
   5.11   Path Info Request Message . . . . . . . . . . . . . . . . 15
   5.12   Path Info Message . . . . . . . . . . . . . . . . . . . . 15
   5.12.1  Path Info  . . . . . . . . . . . . . . . . . . . . . . . 16
   6.    References . . . . . . . . . . . . . . . . . . . . . . . . 16
   7.    Security Considerations  . . . . . . . . . . . . . . . . . 17
   8.    Authors' Addresses . . . . . . . . . . . . . . . . . . . . 17
   9.    Full Copyright Statement . . . . . . . . . . . . . . . . . 18













Lillethun, Lange, Weinberger     Expires August 20, 2006       [Page  2]

Internet-Draft  Simple Path Control Protocol Specification February 2006

1. Introduction

   Various methods exist that allow paths, including lightpaths, to be
   established within a network. The Simple Path Control Protocol was
   developed to enable external processes, including applications, to
   communicate messages that allow for such paths to be created, deleted
   and monitored. SPC defines a message that can be sent to a server
   that is capable of establishing a path on lower-layer network
   elements. After receiving such a request, the server is responsible
   for identifying the appropriate path through the controlled network
   topology and configuring it to fulfill the request. SPC also provides
   facilities for explicitly releasing a path when it is no longer
   needed, and for simple query facilities about the current network
   state.

   The Simple Path Control Protocol also can be used in conjunction with
   other services, for example access control methods, such as AAA, and
   with resource scheduling services.

2. Definitions

   SPC server:
      A server that listens for and handles SPC request messages and
      sends SPC responses back to the requester.

   SPC client:
      Any system or process that sends requests to an SPC server using
      the SPC protocol.

   lambda (lambda ID):
      In a DWDM system, the specific wavelength of light used on a
      defined path. The value of lambda is typically an opaque
      identifier of which wavelength is being specified (e.g. lambda 1).

   lambda path:
      A path through the optical network where individual packets are
      not examined while in transit. A lambda path is usually denoted by
      the address of its two optical endpoints and a lambda ID.

   host:
      Any end system or computing resource. Hosts are identified by a
      unique identifier (such as IP address) that is specified in the
      relevant SPC messages.

   node:
      A network element, as in a graph representation of the network. A
      node MAY be an Ethernet switch, OXC where a lambda path can be
      terminated (i.e. the "edge" of the optical network), network host,
      or any other type of network element.

   path (network path):
      As in graph terminology, a set of edges without loops that is
      established between two network nodes (typically two hosts). A
      path MAY include a specific lambda path.

Lillethun, Lange, Weinberger     Expires August 20, 2006       [Page  3]

Internet-Draft  Simple Path Control Protocol Specification February 2006

   potential path (path candidate):
      A set of edges without defined loops; a path that is not yet
      established but could be used to connect two network nodes
      (typically two hosts).

   path ID:
      A unique, opaque identifier value that is assigned to each
      established network path. Path IDs are not assigned to potential
      paths.

   resource (network resource):
      Any component of the network which is used by a path and can only
      be used by paths a limited number of times (usually once) or in a
      limited quantity.

   resource ID (RID):
      A unique, opaque identifier value that is assigned to each network
      resource.

3. Overview

   3.1 Request-Response Interaction

      The intended conversation between an SPC client and server is that
      of a simple request-response. Each request or response is a single
      SPC message. The SPC server never sends an unsolicited response to
      a client, and it only sends a single response for each request
      (except for keepalive and quit requests, which do not receive a
      response). Outside the context of a request-response pair, the
      protocol is basically stateless (i.e. no finite state machine of
      client and server is meaningful in the context of processing SPC
      messages). However, the network itself is not stateless. There is
      a distinct difference between successful setup of a path and
      failure to set up a path. Thus, it is important that SPC provides
      reliable message delivery. For this reason, SPC uses TCP as the
      underlying transport protocol. SCTP is another potential transport
      protocol for these messages.

   3.2 Typical Session

      A sample user session consists of establishing a TCP connection to
      the SPC server, sending one or more SPC requests, receiving
      replies to each request (except for keepalive and quit requests),
      and eventually breaking the TCP connection. It is permissible to
      send multiple request messages before receiving the response to
      the first request, and the SPC server should handle requests in
      the order received. A Quit message to notify the server of the
      intent to disconnect is provided, but its use SHOULD NOT be needed
      to successfully end a user session. No Hello message is provided.
      A Keepalive message is defined, in case the SPC server implements
      a timeout policy.




Lillethun, Lange, Weinberger     Expires August 20, 2006       [Page  4]

Internet-Draft  Simple Path Control Protocol Specification February 2006

   3.3 Type-Length-Value Encoding

      To allow for extensions to this protocol, SPC messages are encoded
      using a Type-Length-Value scheme. Each message is preceded by a
      message header containing a protocol version number, hash of the
      message, timestamp, an opaque message identifier, a value
      indicating message type, and the number of octets that follow with
      data for the given message.

4. SPC Requests

   The following requests MAY be sent by a client to an SPC server.
   These requests constitute the primitive operations that MAY be
   accomplished using SPC. It is relevant to note that some higher-order
   requests MAY be built out of a sequence of these low-order
   primitives.

   4.1 Message Header

      All SPC messages begin with a message header of the same format.
      The header contains a field to denote the protocol version, a
      hash and timestamp that can be used for message security, a
      message ID, the message type, and lastly the length of the
      remainder of the message (i.e. the length does not include the
      length of this header).

   4.2 Keepalive Message

      A Keepalive message SHOULD be sent from the client to the server
      to maintain an active application-level session. An SPC server MAY
      implement a timeout policy, but all SPC servers MUST be able to
      accept Keepalive messages even if they do not implement a timeout
      policy. No response is expected to a Keepalive message.

   4.3 Quit Message

      To notify the SPC server that the client has finished sending
      requests and is about to close its connection, the client sends
      the SPC server a Quit message. An SPC server SHOULD NOT require
      the use of Quit messages, but MUST be able to accept them. No
      response is expected for a Quit message.

   4.4 Find Path Message

      To request that the SPC server calculate a path between two
      network nodes (but not create that path), a client sends a Find
      Path message which contains identifiers for the endpoint nodes.
      The SPC server finds all non-redundant possible paths and returns
      a Find Path Result message containing the list of paths, and a
      rating and list of resources needed for each path found.





Lillethun, Lange, Weinberger     Expires August 20, 2006       [Page  5]

Internet-Draft  Simple Path Control Protocol Specification February 2006

   4.5 Create Path Message

      To request the creation of a new network path, a client sends a
      Create Path message which contains a list of resources needed to
      create the path.  The SPC server will attempt to create the path
      with the specified network resources. It then sends a Create Path
      Result message, which contains a status value to indicate success
      or failure, the path ID of the new path, and the VLAN ID (VID) if
      a VLAN was created.

   4.6 Find and Create Path Message

      To request the creation of a new network path without handling
      individual resources on the client, a Find and Create Path message
      SHOULD be sent. Like a Find Path message, it contains the public
      IP addresses of the endpoint network nodes. The SPC server
      attempts to find a path and then create that path on the network.
      If more than one path is possible between the endpoints, the SPC
      server can use an optimization mechanism to determine which path
      to use. A Create Path Result message, identical to the Create Path
      Result message that is used to respond to Create Path messages, is
      returned to the client to indicate success or failure and report
      the path ID and VID (if applicable).

   4.7 Teardown Path Message

      To request the teardown of an existing path, a client sends a
      Teardown Path message, which contains the path ID of the path to
      be torn down. The server will then respond with a Result message,
      which contains a status value to indicate success or failure.

   4.8 Path Info Request

      To request a list of all established paths, a client sends a Path
      Info Request message to the server. The server returns a Path Info
      message to the client, listing all information about all
      established paths.

5. SPC Message Encodings

   This section specifies the network encoding of each SPC message. All
   messages sent by any SPC client or server begin with a Message
   Header. Unless otherwise specified, all values are unsigned integers,
   encoded in network byte order. This protocol uses a Type-Length-value
   (TLV) scheme for extensibility and error detection.










Lillethun, Lange, Weinberger     Expires August 20, 2006       [Page  6]

Internet-Draft  Simple Path Control Protocol Specification February 2006

   5.1 Message Header

      The Message Header precedes every message sent. It tells the SPC
      server the type and length of the message that follows.

                    1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  version (2)  |          header_len           | hashname_len  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           hash_bits           |  ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          message_id           | message_type  | message_length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 message_length |
+-+-+-+-+-+-+-+-+

   version:
      1 octet value specifying the protocol version. This value
      indicates to the receiveing computer how to interpret the
      remainder of the header (thus allowing for later changes to the
      header format). For this version of the protocol, this value MUST
      be "2" (two).

   header_len:
      2 octets in network byte order, indicating the length (in octets)
      of the remainder of the message header. This value does not include
      the size of the version and header_len fields.

   hashname_len:
      1 octet, giving the number of characters in the hashname string

   hashname:
      Sequence of ASCII characters (1 octet each) specifying the name of
      the hashing function used to generate hash. The number of characters
      is specified by hashname_len, and there is no terminating character
      (e.g. no ''). The hashing function may be a simple hash that is
      useful for error checking but not secure (e.g. "MD5") or one that
      uses a shared secret key to ensure the integrity of the message
      (e.g. "HMAC-SHA-1").

   hash_bits:
      2 octets in network byte order, giving the number of bits in the hash.








Lillethun, Lange, Weinberger     Expires August 20, 2006       [Page  7]

Internet-Draft  Simple Path Control Protocol Specification February 2006

   hash:
      Sequence of octets, specifying the hash of this message including
      all subsequent parts of the header (starting with the next field
      after the hash). If hash_bits is not an octet multiple, then
      the hash is padded with extra bits to make it an octet multiple.
      Therefore, the length of this field in octets is given by
      ((hash_bits - 1) / 8 + 1) where '/' specifies integer division,
      dropping the remainder. Extra bits that were used for padding
      may be ignored.

   timestamp:
      4 octets in network byte order, representing a timestamp as
      the number of seconds elapsed since 0h UTC on 1 January 1970.
      This field may be used to allow the SPC server to expire old
      messages, thus avoiding errors due to exceptionally slow packet
      delivery and limiting the usefulness of replay attacks.

   message_id:
      2 octets in network byte order, identifying this message. When a
      client sends a message to a server, it specifies a message ID.
      Then when the server sends a response message back to the client,
      it will send the message with the same message ID as the original
      request.

   message_type:
      1 octet value, indicating the type of message that follows the
      header. The possible values for message_type are as follows:

0  Invalid Message - (not actual msg but indication of not being a msg)
1  Keepalive Message
2  Quit Message
3  Result Message
4  Find Path Message
5  Find Path Result Message
6  Create Path Message
7  Create Path Result Message
8  Find and Create Path Message
9  Teardown Message
10 Path Info Request Message
11 Path Info Message

   message_len:
      2 octets in network byte order, indicating the length (in octets)
      of the message that follows. This value does not include the size
      of the Message Header, only the message after it.

   5.2 Keepalive Message

      The Keepalive message has no body. It consists of a Message Header
      with message_type "1" and message_len "0".





Lillethun, Lange, Weinberger     Expires August 20, 2006       [Page  8]

Internet-Draft  Simple Path Control Protocol Specification February 2006

   5.3 Quit Message

      The Quit message has no body. It consists of a Message Header with
      message_type "2" and message_len "0".

   5.4 Find Path Message

      The Find Path message asks the SPC server to find all paths with
      at least the specified bandwidth between two hosts, but not to
      create the path.

                    1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    id_type    |             endhost_1 (16 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    endhost_1   |             endhost_2 (16 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    endhost_2   |                   bandwidth
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    bandwidth   |    ut_len     | <user_type>...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    grp_len    | <user_grp>...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   id_type:
      1 octet indicating the identifier type used to identify the end
      hosts in this message. The possible values for id_type are as
      follows:

0 reserved
1 Opaque Node Identifier
2 MAC Address
3 reserved
4 IPv4 Address
5 reserved
6 IPv6 Address

   endhost_1:
      16 octets in network byte order, containing the node identifier of
      one of the two end hosts. The format of the identifier is
      specified by the id_type field. If the identifier is smaller than
      16 octets (128 bits) then it MUST be followed by enough "0" octets
      to total 16 octets.

   endhost_2:
      16 octets in network byte order, containing the node identifier of
      the other end host. The format of the identifier is specified by
      the id_type field. If the identifier is smaller than 16 octets
      (128 bits) then it MUST be followed by enough "0" octets to total
      16 octets.




Lillethun, Lange, Weinberger     Expires August 20, 2006       [Page  9]

Internet-Draft  Simple Path Control Protocol Specification February 2006

   bandwidth:
      4 octets in network byte order, giving the bandwidth in kilobits
      per second (kbps) needed for this path. An SPC client MAY also
      specify a value of "0" (zero). The SPC server then does not make
      any guarantees about how much bandwidth that path might or might
      not provide (some paths MAY have more total bandwidth than
      others).

   ut_len:
      1 octet, giving the number of characters in the user_type string

   user_type:
      Sequence of ASCII characters (1 octet each) specifying the name of
      the user or user type requesting a path. The number of characters
      is specified by ut_len, and there is no terminating character
      (e.g. no '').

   grp_len:
      1 octet, giving the number of characters in the user_grp string

   user_grp:
      Sequence of ASCII characters (1 octet each) specifying the group
      to which the user requesting a path belongs. The number of
      characters is specified by grp_len, and there is no terminating
      character (e.g. no '').






























Lillethun, Lange, Weinberger     Expires August 20, 2006       [Page 10]

Internet-Draft  Simple Path Control Protocol Specification February 2006

   5.5 Find Path Result Message

      The Find Path Result message is sent by the SPC server in response
      to a Find Path message.  It contains a status code to indicate
      success or failure, and a list of paths between the requested end
      hosts. Each path in the list has a rating to indicate the quality
      of the path, and a list of resource IDs for the resources needed
      to establish that path.

                     1                   2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     status      |          num_paths          |    ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   status:
      1 octet unsigned value indicating success or the failure mode of
      the operation. Success is indicated by 0 (zero) and failure by a
      non-zero value. Failure codes are context sensitive (i.e. the
      value of status might represent a different failure mode than the
      same value for status in a different message), and the status
      values for this message are as follows:

0  Success (no failure)
1  Unknown or Unspecified Failure
2  Not Implemented
3  Network Failure (could also indicate a malformed message)
4  Datasource Failure (i.e. could not connect to the data source)

5-199   Reserved for Future Use
200-255 Custom (used for custom error values)

   num_paths:
      2 octets in network byte order, representing the number of paths
      found between the end hosts. If there are no paths connecting the
      two end hosts, then status is "0" (zero) for success and num_paths
      is "0" (zero) to indicate there are no paths. If an error occured,
      status is non-zero and num_paths is "0" (zero) to indicate there
      are no paths in the list.

   :
      A list of paths found between the end hosts, listed one after the
      other where the format of a single path is as follows. This list
      is empty (0 octets long) if num_paths is "0" (zero).











Lillethun, Lange, Weinberger     Expires August 20, 2006       [Page 11]

Internet-Draft  Simple Path Control Protocol Specification February 2006

         5.5.1 Path

                     1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            rating             |            num_res            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           ...                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   rating:
      2 octets in network byte order, indicating the relative quality of
      the path. Only positive integer values are allowed, and smaller
      values indicate a better (more favorable) rating. This rating is
      strictly relative; the absolute value of the rating field is not
      defined in this protocol to have any significance.

   num_res:
      2 octets in network byte order, indicating the number of resources
      needed by the path.

   :
      An list of resource ID (rid) values for the resources needed by
      the path, listed in order between the source and destination
      nodes. (For a bidirectional path, the order MAY alternatively be
      inverted.) See 'rid' below.

   rid:
      4 octets in network byte order, indicating the resource ID (rid)
      for one of the resources needed to create this path.


   5.6 Create Path Message

      The Create Path message is sent to the SPC server to request the
      allocation of a path over the network.

                     1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            num_res            |            ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             ...           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   num_res:
      2 octets in network byte order, indicating the number of resources
      to be configured for the path.

   :
      An ordered list of resource ID (rid) values for the resources to
      be added to the path, listed one after the other. See 'rid' below.



Lillethun, Lange, Weinberger     Expires August 20, 2006       [Page 12]

Internet-Draft  Simple Path Control Protocol Specification February 2006

   rid:
      4 octets in network byte order, indicating the resource ID (rid)
      for one of the resources needed to create this path.

   5.7 Create Path Result Message

      The Create Path Result message is sent from the SPC server to the
      client after the SPC server has finished handling a Create Path
      message.

                     1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    status     |           path_id             |      vid
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      vid       |
+-+-+-+-+-+-+-+-+

   status:
      1 octet unsigned value indicating success or the failure mode of
      the operation. Success is indicated by "0" (zero) and failure by a
      non-zero value. Failure codes are context sensitive (i.e. the
      value of status might represent a different failure mode than the
      same value for status in a different message), and the status
      values for this message are as follows:

0  Success (no failure)
1  Unknown or Unspecified Failure
2  Not Implemented
3  Network Failure (could also indicate a malformed message)
4  Datasource Failure (i.e. could not connect to the data source)

5-199   Reserved for Future Use
200-255 Custom (used for custom error values)

   path_id:
      2 octets in network byte order, giving the path ID of the path
      just created. This path ID SHOULD be kept by the client and will
      be used to release the path when done. If status indicated a
      failure occurred then path_id will be "0" (zero), which is an
      invalid path ID.

   vid:
      2 octets in network byte order, indicating the VLAN ID for the
      VLAN established by the path. If no VLAN was established, or if a
      failure occurred, vid will be "0" (zero) which is an invalid VLAN
      ID. The vid SHOULD NOT ever be "1" (one) as that is the vid for
      the default VLAN.







Lillethun, Lange, Weinberger     Expires August 20, 2006       [Page 13]

Internet-Draft  Simple Path Control Protocol Specification February 2006

   5.8 Find and Create Path Message

      The Find and Create Path message is a combination of the Find Path
      and Create Path messages. By combining these messages, the client
      is relieved of the responsibility of dealing with resources, and
      the SPC server MAY choose to implement optimizations that are not
      possible when dealing with the two operations separately. The SPC
      server chooses a path between the end hosts that provides at least
      the requested bandwidth and creates that path. Then the server
      responds with a Create Path Result message.

                     1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    id_type    |             endhost_1 (16 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    endhost_1   |             endhost_2 (16 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    endhost_2   |                   bandwidth
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    bandwidth   |    ut_len     | <user_type>...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    grp_len    | <user_grp>...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   id_type:
      1 octet indicating the identifier type used to identify the end
      hosts in this message. The possible values for id_type are as
      follows:

0 reserved
1 Opaque Node Identifier
2 MAC Address
3 reserved
4 IPv4 Address
5 reserved
6 IPv6 Address

   endhost_1:
      16 octets in network byte order, containing the node identifier of
      one of the two end hosts. The format of the identifier is
      specified by the id_type field. If the identifier is smaller than
      16 octets (128 bits) then it MUST be followed by enough "0" octets
      to total 16 octets.

   endhost_2:
      16 octets in network byte order, containing the node identifier of
      the other end host. The format of the identifier is specified by
      the id_type field. If the identifier is smaller than 16 octets
      (128 bits) then it MUST be followed by enough "0" octets to total
      16 octets.




Lillethun, Lange, Weinberger     Expires August 20, 2006       [Page 14]

Internet-Draft  Simple Path Control Protocol Specification February 2006

   bandwidth:
      4 octets in network byte order, giving the bandwidth in kilobits
      per second (kbps) needed for this path. An SPC client MAY also
      specify a value of "0" (zero). The SPC server then does not make
      any guarantees about how much bandwidth that path might or might
      not provide (some paths MAY have more total bandwidth than
      others).

   ut_len:
      1 octet, giving the number of characters in the user_type string

   user_type:
      Sequence of ASCII characters (1 octet each) specifying the name of
      the user or user type requesting a path. The number of characters
      is specified by ut_len, and there is no terminating character
      (e.g. no '').

   grp_len:
      1 octet, giving the number of characters in the user_grp string

   user_grp:
      Sequence of ASCII characters (1 octet each) specifying the group
      to which the user requesting a path belongs. The number of
      characters is specified by grp_len, and there is no terminating
      character (e.g. no '').

   5.9 Teardown Path Message

      The Teardown message is sent from a client to the server to
      request that an existing path be torn down. The SPC server will
      respond to a Teardown message with a Result message.

                     1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           path_id             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   path_id:
      2 octets in network byte order, giving the path ID of the path to
      tear down.

   The possible status values for the responding Result message are:

0  Success (no failure)
1  Unknown or Unspecified Failure
2  Not Implemented
3  Network Failure (could also indicate a malformed message)
4  Datasource Failure (i.e. could not connect to the data source)
5  No Such ID

5-199   Reserved for Future Use
200-255 Custom (used for custom error values)


Lillethun, Lange, Weinberger     Expires August 20, 2006       [Page 15]

Internet-Draft  Simple Path Control Protocol Specification February 2006

   5.10 Result Message

      The Result message is a generic response message that is used to
      respond to requests that do not need additional data in the
      response.

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|    status     |
+-+-+-+-+-+-+-+-+

   status:
      1 octet unsigned value indicating success or the failure mode of
      the operation. Success is indicated by "0" (zero) and failure by a
      non-zero value. Failure codes are context sensitive (i.e. the
      value of status might represent a different failure mode than the
      same value for status in a different message). See the appropriate
      request message for a detailed list of error values.

   5.11 Path Info Request Message

      The Path Info Request message has no body. It consists of a
      Message Header with msg_type "10" and msg_len "0".

   5.12 Path Info Message

      The Path Info message is sent from the server to a client in
      response to a Path Info Request message. It contains all relevant
      information about the currently allocated paths on the optical
      network.

      The Path Info Response message is a variable length message,
      consisting of a value giving the number of paths contained in the
      message. Following that are the given number of serialized path
      info sequences.

                     1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    status     |            num_paths            |  ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+














Lillethun, Lange, Weinberger     Expires August 20, 2006       [Page 16]

Internet-Draft  Simple Path Control Protocol Specification February 2006

   status:
      1 octet value indicating success or failure of the request.
      Success is indicated by a value of "0" (zero), and failure is
      indicated by a non-zero value. The remaining parameters might only
      be meaningful if status is "0" (zero). The possible failure values
      are:

0  Success (no failure)
1  Unknown or Unspecified Failure
2  Not Implemented
3  Network Failure (could also indicate a malformed message)
4  Datasource Failure (i.e. could not connect to the data source)
5  More Data (more paths exist than could be returned in this message)

5-199   Reserved for Future Use
200-255 Custom (used for custom error values)

   num_paths:
      2 octets in network byte order, that indicate the number of path
      info structs that follow. If status is "5" then num_paths is set
      to the maximum number of paths that a message can contain, and
      that many paths are contained in the message but more paths exists
      that could not be included.

      5.12.1 Path Info

                     1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            path_id            |            vlan_id            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            srcnode            |            dstnode            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            lambda             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   path_id:
      2 octets in network byte order, giving the path ID of the path.

   vlan_id:
      2 octets in network byte order, giving the VLAN ID (or VID) of the
      VLAN. This value is "0" (zero) if no VLAN was created.

   srcnode:
      2 octets in network byte order, giving the node ID of the ingress
      optical node.

   dstnode:
      2 octets in network byte order, giving the node ID of the egress
      optical node.

   lambda:
      2 octets in network byte order, giving the lambda number the path
      is using.

Lillethun, Lange, Weinberger     Expires August 20, 2006       [Page 17]

Internet-Draft  Simple Path Control Protocol Specification February 2006

6. References

   [1]  Aboba, B., Wood, J., "Authentication, Authorization and
        Accounting (AAA) Transport Profile", RFC 3539, June 2003.

   [2]  Bellovin, S., Ioannidis, J., Keromytis, A., Stewart, R., "On the
        Use of Stream Control Transmission Protocol (SCTP) with IPsec",
        RFC 3554, July 2003.

   [3]  Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS)
        Signaling Functional Description", RFC 3471, January 2003.

   [4]  Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS)
        Signaling Resource ReserVation Protocol-Traffic Engineering
        (RSVP-TE) Extensions", RFC 3473, January 2003.

   [5]  Kompella, K., Rekhter, Y., "OSPF Extensions in Support of
        Generalized Multi-Protocol Label Switching", Internet Draft,
        October 2003.

   [6]  Kompella, K., Rekhter, Y., "Routing Extensions in Support of
        Generalized Multi-Protocol Label Switching", Internet Draft,
        October 2003.

   [7]  Mannie, Eric, "Generalized Multi-Protocol Label Switching
        Architecture", Internet Draft, November 2003.

   [8]  Steinberger, R., Nicklass, O., "Definitions of Managed Objects
        for Circuit to Interface Translation", RFC 3201, January 2002.

7. Security Considerations

   This protocol provides the ability to send a hash of the message
   according to any hashing function the sender chooses (subject to
   the receiver's ability to perform the same hashing function). While
   a simple hashing function may be used to detect transmission errors,
   a sender may choose to send or a reciever may choose only to trust
   messages that are hashed with a more secure algorithm that guarantees
   the integrity of the message. For example, HMAC-SHA-1 uses a shared
   secret key to ensure the message has not been altered.

   In addition, the timestamp field in the message header can be used to
   prevent complete, already hashed, messages from being intercepted
   and rebroadcast later. This mechanism complements the hashing
   function in increasing the difficulty of impersonating a client.

   There is no mechanism provided in this protocol to prevent messages
   from being intercepted and read by a third party. However, the
   messages could easily be encrypted with an encryption method that is
   agreed upon beforehand between the server and any clients.





Lillethun, Lange, Weinberger     Expires August 20, 2006       [Page 18]

Internet-Draft  Simple Path Control Protocol Specification February 2006

8. Authors' Addresses

   David Lillethun
   International Center for Advanced Internet Research
   Northwestern University
   750 North Lake Shore Drive, Suite 600
   Chicago, IL 60611
   USA
   EMail: davel@alumni.northwestern.edu

   Jack Lange
   International Center for Advanced Internet Research
   Northwestern University
   750 North Lake Shore Drive, Suite 600
   Chicago, IL 60611
   USA
   EMail: jarusl@northwestern.edu

   Jeremy Weinberger
   International Center for Advanced Internet Research
   Northwestern University
   750 North Lake Shore Drive, Suite 600
   Chicago, IL 60611
   USA
   EMail: jeremy@isp.northwestern.edu

   URL: http://www.icair.org/

9. Full Copyright Statement

   Copyright (C) The Internet Society (2006). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.














Lillethun, Lange, Weinberger     Expires August 20, 2006     [Page 19]
Advertisements
Dave Lillethun

Dave Lillethun

Dave Lillethun is an assistant professor in the Computer Science & Software Engineering department at Seattle University.

View Full Profile →

Email:
Follow me on Twitter