Internet Draft
Network Working Group John Yu, Zaffire
Internet Draft Fong Liaw, Zaffire
Expiration Date: May 2001 Eric Gray, BrightWave
John Drake, Calient Networks
Jonathan Lang, Calient Networks
Ayan Banerjee, Calient Networks
Greg Bernstein, Ciena
Yakov Rekhter, Cisco Systems
George Swallow, Cisco Systems
Kireeti Kompella, Juniper Networks
Robert Rennison, Laurel Networks,
Yangguang Xu, Lucent Technology
Dimitrios Pendarakis, Tellium
Nooshin Komaee, Tellium
Raj Jain, Nayna Networks
Zhensheng Zhang, Sorrento Networks
November, 2000
RSVP Extensions in Support of OIF Optical UNI Signaling
draft-yu-mpls-rsvp-oif-uni-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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 as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This draft defines a signaling mechanism based on RSVP-TE ([2]) to
support an Optical User Network Interface (UNI). This effort is in
part driven by work in the OIF as well as the recent draft on
signaling requirements for the optical UNI ([3]), and is consistent
with recent work on Generalized MPLS (see [4], [5], [6], and [7]) in
IETF. The main function of this draft is to identify the relevant
mechanisms in RSVP-TE (including further extensions) to satisfy
functional requirements for an Optical UNI. This draft reflects
Yu, et al. [page 1]
draft-yu-mpls-rsvp-oif-uni-00.txt November 2000
ongoing work at the Optical Interworking Forum (OIF), however, not
all of the concepts/requirements have been approved by the OIF.
Yu, et al. [Page 2]
draft-yu-mpls-rsvp-oif-uni-00.txt November 2000
Table of Contents
1 Introduction
2 Overview
2.1 Optical UNI (O-UNI) signaling requirements and RSVP objects
2.2 Basic RSVP protocol operation
2.3 Use of RSVP-TE and Generalized MPLS signaling for O-UNI
2.3.1 O-UNI interfaces, control channels, and addressing
2.3.2 Sending O-UNI RSVP messages
2.3.3 Receiving O-UNI RSVP messages
2.3.4 Reliable messaging
2.3.5 Reservation style
2.3.6 Lightpath identification
2.3.7 Lightpath creation
2.3.8 Lightpath modification
2.3.9 Lightpath deletion
2.3.10 Lightpath status enquiry and response
2.3.11 Node failure detection
3 RSVP Messages and Objects for O-UNI signaling
3.1 O-UNI RSVP Messages
3.1.1 ACK Message
3.1.2 Hello Message
3.1.3 Notify Message
3.1.4 Path Message
3.1.5 PathErr Message
3.1.6 PathTear Message
3.1.7 Resv Message
3.1.8 ResvConf Message
3.1.9 ResvErr Message
3.1.10 ResvTear Message
3.1.11 Srefresh Message
3.2 O-UNI RSVP objects format
3.2.1 Sender Template Object
3.2.2 Session Object
3.2.3 Session Attribute Object
3.2.3.1 Format without resource affinities
3.2.3.2 Format with resource affinities
3.2.4 Lightpath_ID Object
3.2.5 GENERALIZED LABEL Object
3.2.6 GENERALIZED LABEL REQUEST Object
3.2.7 LABEL SET Object
3.2.8 SUGGESTED LABEL Object
3.2.9 UPSTREAM LABEL Class
3.2.10 ERROR_SPEC Object
3.2.11 Filter Specification Object
3.2.12 FLOWSPEC Object
3.2.13 SENDER_TSPEC Object
3.2.14 INTEGRITY Object
3.2.15 COMPONENT_INTERFACE_ID Object
3.2.16 MESSAGE_ID Object
3.2.17 MESSAGE_ID_ACK Object
3.2.18 MESSAGE_ID_NAC Object
3.2.19 MESSAGE_ID_LIST Object
3.2.20 POLICY_DATA Class
Yu, et al. [Page 3]
draft-yu-mpls-rsvp-oif-uni-00.txt November 2000
3.2.21 RSVP HOP Object
3.2.22 TIME_VALUES Object
3.2.23 NOTIFY_REQUEST Object
4 References
1. Introduction
There has recently been a significant effort amongst carriers,
service providers, and vendors in the optical networking space to
eliminate proprietary control protocols and develop a common control
plane. The Optical Internetworking Forum (OIF) has initiated work on
an Optical User-Network Interface (O-UNI) as a step in this
direction. Recently, a draft [3] was submitted to the IETF defining
proposed requirements and abstract messages for the Optical UNI.
This document describes how a signaling mechanism based on RSVP-TE
[2] may be used for an Optical UNI. In particular, we identify the
mechanisms already defined for RSVP-TE that can be used to satisfy
the proposed requirements of [3]. This work is also in alignment
with the recent Internet Drafts defining Generalized MPLS signaling
(e.g., [4]).
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 [8].
2. Overview
The purpose of this document is to describe the use of RSVP [15],
RSVP-TE [2], and GMPLS [4] to manage lightpaths at an optical User-
Network Interface (O-UNI). The intent is to sufficiently describe
information of the objects, packet formats, and procedures required
to realize interoperable implementations, with the principle of
leveraging the existing specifications as much as possible. A few
new objects are defined to indicate lightpath attributes that are
unique to O-UNI.
This specification supports only signaling messages and procedures to
establish point-to-point, uni-directional and bi-directional,
lightpaths. Specification for any other type of lightpath is for
further study.
In this document and in [2, 4, 15], we define the directional terms
"source" vs. "destination", "originating" vs. "terminating",
"upstream" vs. "downstream", "previous hop" vs. "next hop", and
"incoming interface" vs. "outgoing interface" with respect to the
direction of light.
Procedures different from [2,4] are underlined to highlight the
differences between this document and [2,4].
2.1 Optical UNI (O-UNI) signaling requirements and RSVP objects
Yu, et al. [Page 4]
draft-yu-mpls-rsvp-oif-uni-00.txt November 2000
As part of an optical UNI, the signaling protocol must have the
capability to create, delete, and modify connections across a
network, as well as query the status of an existing lightpath. Most
of these capabilities may be directly supported by re-using existing
procedures, messages, and objects defined in RSVP-TE [2] and in
Generalized MPLS Signaling [4].
In particular, the optical UNI signaling requirements [3, 17] specify
a set of attributes to be signaled during lightpath creation and
modification. The following table summarizes the optical signaling
attributes and the corresponding RSVP objects. Specific O-UNI related
object formats and usage are described in Section 3.
OPTICAL signaling attribute RSVP object
------------------------------+-------------------------------
Bandwidth | Sender_Tspec [4]
Contract ID | Policy Data [16]
Destination address | Session [2]
Directionality | Upstream Label [4]
Diversity | Session Attribute [2]
| and Generalized Label Request
| Object [4]
Framing Type | Generalized Label Request [4]
Light_Path ID | Lightpath_ID
Propagation Delay | Sender_Tspec [4]
Return code | Error Spec [15]
Service priority | Session Attribute [2]
Source address | Sender Template [2]
Source port/channel | Label Set/Suggest Label [4]
Transparency | Generalized Label Request [4]
User group ID | Policy Data [16]
------------------------------+---------------------------------
2.2 Basic RSVP protocol operation
There are two fundamental RSVP message types: Resv and Path [15]. An
originating user node originates a lightpath establishment request by
transmitting RSVP "Path" messages downstream along the direction of a
lightpath. These Path messages create "path state" in each node
along the way. In response to a Path message, the lightpath
terminating user node sends RSVP reservation request (Resv) messages
upstream towards the lightpath originator. These messages MUST
follow exactly the reverse of the path(s) that the light will travel.
They create and maintain "reservation state" in each node along the
path(s). Resv messages will finally be delivered to the lightpath
originating user node itself. This completes the establishment of a
lightpath. Removal of a reservation state does not automatically
removes its associated path state, but removal of a path state will
remove the reservation states that are associated with it as well.
Path messages are sent with the same source and destination addresses
as the lightpath. On the other hand, Resv messages are sent hop-by-
Yu, et al. [Page 5]
draft-yu-mpls-rsvp-oif-uni-00.txt November 2000
hop; each RSVP-speaking node forwards a Resv message to the unicast
address of a previous RSVP hop.
For each RSVP message type, there is a set of rules for the
permissible choice of object types. These rules are specified using
Backus-Naur Form (BNF) augmented with square brackets surrounding
optional sub-sequences. The BNF implies an order for the objects in
a message. However, in many (but not all) cases, object order makes
no logical difference. An implementation should create messages with
the objects in the order shown for each message, and accept the
objects in any permissible order.
2.3 Use of RSVP-TE and Generalized MPLS signaling for O-UNI
The RSVP protocol operation for lightpath signaling is only specified
over the ingress O-UNI and egress O-UNI. It is required the UNI-Ns to
support the RSVP signaling specified in this document, while it is
not required to support RSVP signaling within the network, provided
the network can carry the signaling information between the two O-
UNIs for the end-to-end lightpath signaling.
2.3.1 O-UNI interfaces, control channels, and addressing
An O-UNI interface may identify one or more regular link(s), or one
or more bundled link(s). Within a bundled link, there may be one or
more component links that have the same characteristics. Generalized
MPLS signaling [4] defines several types of labels that may be
represented in a Generalized Label object. For optical applications
a label may be arbitrarily associated with all or part of a component
link, or may be a superset of multiple component links. A common
understanding of the meaning of the component interface identifier
[11] MUST exist between the user and the network across any O-UNI.
This common understanding may be dynamically derived (e.g. using LMP
[5]), or pre-configured.
In an O-UNI interface, each bundle link is associated with a control
channel. Signaling protocol messages are exchanged over each control
channel that is associated with a control channel interface. The
control channel interface MAY be numbered (with an IP address) or May
be unnumbered (in which case it is identified by a node's IP address
and a unique identifier such as an ifindex value). Support for
unnumbered O-UNI interface is optional. Furthermore, one or more
control channels may transmit and receive their protocol messages via
the same signaling transport control channel interface, which MAY be
direct IP link (single IP hop) or over an IP network (multiple IP
hop), as specified in [14].
2.3.2 Sending O-UNI RSVP messages
When sending an RSVP message over a directly connected signaling
transport channel [14], the message format defined in [15] (section
3.3) is used, i.e. messages are sent as "raw" IP datagrams with
protocol number 46.
Yu, et al. [Page 6]
draft-yu-mpls-rsvp-oif-uni-00.txt November 2000
RSVP Path, PathTear, and ResvConf messages are sent with an IP router
alert option. The IP destination and source address of Path and
PathTear messages are the lightpathÆs source and destination
addresses.
RSVP Resv, ResvTear, ResvErr, PathErr, Ack, Srefresh messages are
routed hop-by-hop, and their IP destination address is set to the
previous RSVP hop. The source address is the previous hop that sends
the message, not the originating hop.
The Notify message MAY be generated at any time to allow expedited
notification of change in the status of a lightpath. The IP
destination address is set to the IP address of the intended
receiver. The Notify message is sent without the router alert
option.
When the UNI RSVP messages are delivered over a non-directly
connected signaling transport channel (out-of-fiber, out-of-band, co-
located or non-co-located), the messages shall be encapsulated in IP-
in-IP header before the transmission [14].
2.3.3 Receiving O-UNI RSVP messages
A node SHALL verify a received O-UNI RSVP message as specified in
[2,4]. In addition, if a Path message is to be processed by a
receiving node, the receiving RSVP node SHALL verify that the IP
address in the RSVP_HOP object matches one of its adjacent nodeÆs O-
UNI interface identifiers and associates the message with the matched
O-UNI interface. If a match does not exist, an error code ôrouting
problemö SHALL be reported in a PathErr Message.
2.3.4 Reliable messaging
To support reliable messaging across the O-UNI, the Message_ID object
and Ack desired flag of [10] MUST be used in every O-UNI RSVP
message.
Message identification and acknowledgment is done on a per hop basis.
All types of MESSAGE_ID objects contain a message identifier. The
identifier MUST be unique on a per object generator's IP address
basis. No more than one MESSAGE_ID object may be included in an RSVP
message. Each message containing a MESSAGE_ID object may be
acknowledged via a MESSAGE_ID_ACK object, when so indicated.
MESSAGE_ID_ACK and MESSAGE_ID_NACK objects may be sent piggybacked in
unrelated RSVP messages or in RSVP Ack messages. RSVP messages
carrying any of the three object types may be included in an RSVP
Bundled message. When included, each object is treated as if it were
contained in a standard, non-bundled, RSVP message.
If a MESSAGE_ID_ACK object of a RSVP Message cannot be piggybacked in
a pending RSVP message immediately, a downstream (upstream) node
SHALL generate an Ack message including the MESSAGE_ID_ACK object to
Yu, et al. [Page 7]
draft-yu-mpls-rsvp-oif-uni-00.txt November 2000
its upstream (downstream) node. This allows a faster confirmation for
the message.
2.3.5 Reservation style
A reservation request includes a set of options that are collectively
called the reservation "style" [15]. One reservation option concerns
the treatment of reservations for different traffic sources within
the same session: make a "distinct" reservation for each upstream
traffic source, or make a single reservation that is "shared" among
all selected upstream traffic sources.
The supported reservation styles at the O-UNI interface MAY be Fixed
Format (FF) style and Shared-Explicit (SE) style to perform the
"make-before-break" for lightpath modification. A FF-style
reservation reserves the resource for a distinctive upstream traffic
source. An FF-style reservation request creates a distinct
reservation for traffic from a particular upstream source, not
sharing them with other upstream traffic sources for the same
session. An SE-style reservation reserves the resource for one or
more upstream traffic sources. An SE-style reservation creates a
single reservation shared by selected upstream traffic sources. It
allows a receiver to explicitly specify the set of upstream traffic
sources to be included.
2.3.6 Lightpath identification
A new Lightpath_ID object is introduced to uniquely identify a
lightpath throughout the optical network. It SHOULD be assigned by
the network.
2.3.7 Lightpath creation
To create a lightpath, the user O-UNI node creates an RSVP Path
message with a session type of LSP_TUNNEL_IPv4 and inserts a
GENERALIZED LABEL_REQUEST object into the Path message. The
GENERALIZED LABEL_REQUEST object indicates that a label binding for
this lightpath is requested and also provides an indication of the
characteristics, such as desired link protection, encoding, of the
light path.
To create a bi-directional lightpath, an UPSTREAM LABEL Object MUST
be inserted in the Path Message. Therefore, if the encoding type in a
GENERALIZED LABEL REQUEST object indicates a bi-directional medium
type, an UPSTREAM LABEL object MUST be inserted in the Path message;
if no such an UPSTREAM LABEL object is inserted, an error code
"incompatible" SHALL be reported in PathErr Message.
Furthermore, during a lightpath creation, in order to provide the
capability of lightpath modification later on after the ligthpath is
established, it MUST insert a SESSION_ATTRIBUTE Object and indicates
"SE Style desired" in the Flag field.
Yu, et al. [Page 8]
draft-yu-mpls-rsvp-oif-uni-00.txt November 2000
2.3.8 Lightpath modification
Lightpath modification can only be initiated by a lightpathÆs
originating user node on a lightpath that is established with a ôSE
Style desiredö flag in SESSION ATTRIBUTE Object. It uses the
bandwidth-increase "make before break" procedure as described in [2].
The following describes the procedure in more detail.
To effect a modification, the lightpath originating user node picks a
new LSP ID and forms a new SENDER_TEMPLATE. Thereafter the node
sends a new Path Message using the original SESSION object and the
new SENDER_TEMPLATE with the new characteristics of the lightpath.
It continues to use the old lightpath and refresh the old Path
message. The shared SESSION object and SE style allow the LSP to be
established sharing resources with the old LSP. Once the user node
receives a Resv message for the new LSP, it MUST transition traffic
to it and tear down the old LSP by sending a PathTear message toward
the network node.
The lightpath modification is not required for UNI 1.0 [13]. It may
be required in the future specification for OIF.
2.3.9 Lightpath deletion
There are three scenarios for lightpath deletion: deletion from an
originating user, deletion from a terminating user, and deletion from
a network node.
A lightpath originating user node SHALL send a PathTear message
toward the network to delete a lightpath.
A terminating user node SHALL send a ResvTear message toward its
upstream nodes to delete a lightpath. Once a user node receives a
ResvTear message for a lightpath, it MUST send a PathTear message
toward the network to completely delete the lightpath.
A network node MAY send a PathErr message with error code set to
ônetwork initiated deletion, normalö to request the originating user
node to delete the lightpath. If the network also removes its path
state, it MUST set the Path_State_Removed flag in the PathErr message
and also send a PathTear message toward downstream.
2.3.10 Lightpath status enquiry and response
The purpose of lightpath status enquiry and response identified so
far has been to allow adjacent user and network nodes to re-
synchronize their lightpath states when necessary, in particular
after a link or node failure. Potentially, there are a large number
of lightpath states to be re-synchronized. Therefore, the procedure
MUST allow the re-synchronization to occur efficiently. This
specification uses the Srefresh message [10] for efficiency.
Yu, et al. [Page 9]
draft-yu-mpls-rsvp-oif-uni-00.txt November 2000
When a node decides that it is necessary to resynchronize its
lightpath state with its adjacent node, it SHALL send Srefresh
messages to refresh the Message_IDs of some or all active Resv and
Path Messages. If a lightpath state has been deleted from the
adjacent node before the re-synchronization, the adjacent node MUST
respond with a Message_Id_Nack Object for the deleted lightpath. Once
a user node receives a Message_Id_Nack, it SHALL send a Resv or Path
message toward its adjacent node. This would trigger the standard
RSVP resource reservation and recovery procedure.
The above procedure may change the reservation states in a user or
network node. The need for a non-state affecting procedure is for
further study.
2.3.11 Node failure detection
RSVP HELLO procedure [2] MAY be used when a nodeÆs link failure
detection mechanism cannot detect node failure. The RSVP Hello
extension enables RSVP nodes to detect when a neighboring node is not
reachable. The mechanism provides node-to-node failure detection.
When such a failure is detected it is handled much the same as a link
layer communication failure. This mechanism is intended to be used
when notification of link layer failure is not available and
unnumbered links are not used, or when the failure detection
mechanisms provided by the link layer are not sufficient for timely
node failure detection.
This procedure is OPTIONAL and does not require adjacent nodes to
generate HELLO messages at the same time.
3. RSVP Messages and Objects for O-UNI signaling
The following sections describe messages, procedures, and objects
from [2, 4, 16, 15] that are O-UNI related. If this document does not
explicit specify some aspects of messages, procedures, and objects
related to the O-UNI interface, the procedure defined in [4], [2],
[10], [16], and [15] SHALL apply in the order listed.
An O-UNI node MUST support the following RSVP messages:
Path, PathTear, PathErr, Resv, ResvTear, ResvConf, ResvErr, Ack,
Srefresh, Notify
An O-UNI node MAY support the following RSVP messages:
Hello
An O-UNI node MUST support the following RSVP objects:
Error Spec [2, 4, 15], Flow Spec [15], Filter Spec [2], Generalized
Label [4], Generalized Label Request [4], Component_interface_ID
[11], Message_Id [10], Message_Id_Ack [10], Message_Id_Nack [10],
Message_ID_List [10], Session [2], RSVP HOP [15], Sender Template
Yu, et al. [Page 10]
draft-yu-mpls-rsvp-oif-uni-00.txt November 2000
[2], Session Attribute [2], Sender_Tsepc [15], Time Value [15],
Upstream Label [4]
An O-UNI node MAY support the following RSVP objects:
Integrity [15], Label Set [4], Policy Data [15], Suggested Label
[4], Notify Request [4]
3.1 O-UNI RSVP Messages
3.1.1 ACK Message
The ACK message is for reliable messaging across an O-UNI. It has the
following format:
::= [ ]
|
[ [ | ] ... ]
3.1.2 Hello Message
Hello message is for node failure detection. Hello message is
optional. It has the following format:
::= [ ]
[ [ | ] ... ]
3.1.3 Notify Message
The Notify message provides a mechanism to inform ôtargetedö nodes
of LSP related events. Notify messages are only generated after a
Notify Request object has been received. In general, the Notify
message differs from the currently defined error messages (i.e.,
PathErr and ResvErr messages of RSVP) in that it MAY be "targeted" to
a node other than the immediate upstream or downstream neighbor and
that it is a generalized notification mechanism. For UNI 1.0, the
Notify Messages are only generated from the UNI-N to the UNI-C across
the UNIs.
The Notify message MAY be generated at any time to allow expedited
notification of change in the status of a lightpath. Consequently,
both the user and network sides of the Optical UNI MUST be prepared
to receive a Notify message. The IP destination address is set to the
IP address of the UNI-C. The Notify message is sent without the
router alert option. The format of the Notify message is as follows
([4]):
::= [] ::==
[] ::== [...]
Yu, et al. [Page 11]
draft-yu-mpls-rsvp-oif-uni-00.txt November 2000
The ERROR_SPEC object specifies the error and includes the IP address
of either the UNI-N that detected the error or the UNI link that has
failed.
3.1.4 Path Message
The Path messages are used for lightpath creation or modification.
The format for an O-UNI Path message is shown as follows:
::=
[ ]
[ [ | ] ... ]
[ ]
[