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 '\0'). 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 | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | grp_len | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 '\0'). 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 '\0'). 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 | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | grp_len | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 '\0'). 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 '\0'). 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]