Internet Draft
Network Working Group Eric Gray, Fong Liaw, John Yu
Internet Draft Zaffire
Expiration Date: February 2001 John Drake, Jonathan Lang
Calient Networks
Yakov Rekhter, George Swallow
Cisco Systems
Kireeti Kompella
Juniper Networks
Bala Rajagopolan
Tellium
Raj Jain
Nayna Networks
Osama Aboul-Maged
Nortel Networks
Greg Bernstein
Ciena
Zhensheng Zhang
Sorrento Networks
July, 2000
RSVP Extensions in Support of OIF Optical UNI Signaling
draft-gray-mpls-rsvp-oif-uni-ext-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]).
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 ongoing work at
the Optical Interworking Forum (OIF), however, not all of the
concepts/requirements have been approved by the OIF.
Gray, et al Page 01
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 (Optical 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 based on 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
RSVP-TE is one of the candidate protocols described in [3] for Optical
UNI signaling implementation. As part of this Optical UNI, the
signaling protocol must have the capability to create, delete, and
modify lightpaths 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].
This document further extends [2] and [4] to support Optical UNI
signaling requirements as following:
- Use of DREQ and DREP message and procedure as defined in [9] for
Lightpath status enquiry and response.
- Use of Message_ID and Message_Ack objects, Ack_desire flag, and
Ack message as defined in [10] to support confirmation of Lightpath
deletion and reliable messaging.
- PathTear and ResvTear MUST be used to delete a lightpath.
This specification does not specify procedures to support the
following proposed requirements listed in [3]:
- Concept of "indirect interface" as defined in [3]. It is
envisioned that such a requirement can be better serviced
via a network management station.
- Different source and destination user groups. Instead, this
specification allows specifying a single user group using
resource affiliation defined in [2].
Gray, et al Page 02
- Procedures for client registration.
2.1 Use of RSVP-TE and Generalized MPLS signaling for Optical UNI
2.1.1 In-band and out-of-band signaling channels
Optical UNI requires support of in-band and out-of-band signaling
channels. The in-band signaling channel is supported by the use of
a regular link; and the concept of out-of-band signaling channel
is supported by the use of bundled links [8] where a bundled link
consists of a control channel and one or more component links.
When out-of-band signaling channel is used, the procedure,
messages, and objects apply to a bundled link as defined in [4],
[11], [12], and [5] shall be used.
2.1.2 Reliable messaging
To support reliable messaging across the UNI, the Message_ID and
Message_Ack objects, Ack message, and Ack desired flag of [10] MUST
be used in UNI RSVP messages. Acknowledgements apply to hop-by-hop,
as opposed to end-to-end, message delivery.
2.1.2 Lightpath creation
Lightpath creation uses the procedure described in section 2.2
"Operation of LSP tunnels" of [2]. Additional objects and their use
and procedure are defined in Sections 3 and 4 of [4].
2.1.3 Lightpath modification
Lightpath modification uses procedure as described in section 2.5
"Rerouting of Traffic Engineered Tunnels" of [2].
2.1.4 Lightpath deletion
Lightpath deletion can be done by either the client that originated
or terminated the lightpath. The lightpath originator will use the
PathTear message while the lightpath terminator will use the ResvTear
message. Acknowledgement mechanisms of [10] MUST be used to provide
confirmation.
2.1.5 Lightpath status enquiry and response
Any client interested in the lightpath status shall send a Diagnostic
Request (DREQ) message toward the termination end point of the
lightpath. The DREQ message specifies the Session Object, Sender
Template Object, and an ending node. Starting at the last hop of the
lightpath, the DREQ message is sent along the lightpath toward the
sender and start collecting information hop-by-hop in the DREQ. When
the DREQ message reaches the ending node, the message type is changed
to Diagnostic Reply (DREP) and forwarded to the original requestor
node. The DREQ originator can select specific RSVP objects to be
collected by including a DIAG_SELECT object in the DREQ message. The
Gray, et al Page 03
full procedure of DREQ and DREP messages is described in [9].
3. RSVP Message Extensions for OPTICAL UNI signaling
In addition to objects defined in [2] and [4], new objects may need to
be defined to address additional requirements. Additional objects
defined in this specification are OPTIONAL with respect to RSVP and
RSVP-TE.
3.1 Propagation Delay Object
If a propagation delay is desired, the lightpath originator shall
include a Propagation_Delay_object and an ADSPEC object in its Path
Message for the lightpath. Network nodes along the lightpath must
update the ADSPEC and compare the result with the propagation delay
object. If the result is comformant, the node shall forward the Path
message downstream. Otherwise, it shall generate a PathErr message
carrying error code "XXX" (TBD) and discard the Path message.
3.2 Labels
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 a Generalized Label
- in particular the meaning of the link ID portion of the
Generalized Label - must exist between the user and the network
across any Optical UNI. This common understanding may be dynamically
derived (e.g. using LMP [5]), or it may be configured.
This specification uses the Generalized Label, Generalized Label
Request, Upstream Label, Suggested Label and Label Set objects
defined in [4].
4. RSVP objects related to OPTICAL signaling requirements
Optical UNI signaling requirements [3] specify a set of attributes to
be signaled during lightpath creation and modification. The following
table summarizes the RSVP objects that are used to signaling a
particular OPTICAL signaling attribute.
Gray, et al Page 04
OPTICAL signaling attribute RSVP object
------------------------------+-------------------------------
Light_Path ID | Session [2]
Source termination point | Sender Template (or Session) [2]
Destination termination point | Session [2]
Source Termination Point Port | Label Set/Suggest Label [4]
Destination Termination Label | Egress Label [4]
Contract ID | Session Attribute/Name [2]
Framing | Generalized Label Request [4]
Bandwidth | Generalized Label Request [4]
Transparency | Generalized Label Request [4]
Directionality | Upstream Label [4]
Service Level | Session Attribute [2]
Diversity | Session Attribute [2]
| and Generalized Label Request
| Object [4]
Return code | Error Spec
Source user group ID | Session Attributes/LSP_TUNNEL_RA [2]
Destination user group ID | Session Attributes/LSP_TUNNEL_RA [2]
Propagation Delay | Propagation Delay (TBD)
------------------------------+---------------------------------
5. RSVP messages related to OPTICAL UNI signaling
5.1 Path Message
As described in [4], RSVP-TE signaling for support of lightpath
creation allows for labels to be suggested by the upstream LSR
that is sending a Path message. In addition, the upstream node
may provide a label for use in bi-directional setup. The format
for the Path message to be used for the OPTICAL UNI is given below.
::= [ ]
[ ]
[ ]
[