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]
Dave Lillethun, Ph.D. 