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.
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
[ <TIME_VALUES> ]
[ <EXPLICIT ROUTE> ]
<GENERALIZED LABEL_REQUEST>
[ <LABEL SET> | <SUGGESTED LABEL> ]
[ <UPSTREAM LABEL> ]
[ <SESSION_ATTRIBUTE> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER TSPEC>
[ <ADSPEC> <PROPAGATION DELAY> ]
[ <RECORD_ROUTE> ]
The EXPLICIT ROUTE object may be included to provide an egress
label ([4]). Additional explicit hops included in the EXPLICT
ROUTE object MAY be ignored by the Network in the Optical UNI.
Similarly, the RECORD ROUTE object MAY be ignored by the Network
side of the Optical UNI.
Gray, et al Page 05
5.2 Resv Message
RSVP-TE signaling support of the lightpath creation response is
via the OPTICAL UNI Resv message. The format for the OPTICAL UNI
Resv Message is as shown below.
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
[ <TIME_VALUES> ]
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
<FF flow descriptor list> ::= <FLOWSPEC> <FF flow descriptor>
| <FF flow descriptor list> <FF flow descriptor>
<FF flow descriptor> ::= [ <FLOWSPEC> ]
<FILTER_SPEC>
<GENERALIZED LABEL>
[ <RECORD_ROUTE> ]
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
<SE filter spec> ::= <FILTER SPEC> <GENERALIZED LABEL>
[ <RECORD ROUTE> ]
3.4 PathTear Message
The lightpath origination node uses a PathTear message to
explicitly delete a lightpath. The acknowledgement procedures
of [10] are used to provide confirmation. Receiving of a
MESSAGE_ID_ACK object of a PathTear message SHALL be interpreted
to mean that the downstream node has cleared its state
associated with the specified lightpath, but not to mean a
confirmation of an end-to-end lightpath deletion. If a
MESSAGE_ID_ACK object of a PathTear Message cannot be
piggybacked in an pending RSVP message immediately, a downstream
node SHALL generate a Notify message including the
MESSAGE_ID_ACK object to its upstream node. This allows a faster
confirmation for the PathTear message.
5.4 ResvTear Message
A lightpath termination node uses ResvTear Message to explicitly
delete a lightpath. The acknowledgement procedures of [10] are
used to provide confirmation. Receiving of a MESSAGE_ID_ACK
object of a ResvTear message SHALL be interpreted to mean that
the upstream node has cleared its state associated with the
specified lightpath, but not to mean a confirmation of an end-
Gray, et al Page 06
to-end lightpath deletion. If a MESSAGE_ID_ACK object of a
ResvTear Message cannot be piggybacked in a pending RSVP message
immediately, an upstream node SHALL generate a Notify message
including the MESSAGE_ID_ACK object to its upstream node. This
allows a faster confirmation for the ResvTear message.
5.5 Notify Message
The Notify message can 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 format of the
Notify message is given in [4].
5.6 Diagnostic (DREQ) Message
The DREQ Message is used to initiate Lightpath Status Enquiry
required by [3]. The format of the Diagnostic Request (DREQ)
message is given in [9].
Refer to [9] for full procedures on how to handle DREQ messages.
5.7 Diagnostic Reply (DREP) Message
The DREP Message is used to send the collected lightpath status
to originator of the DREQ message. It has the same format as
the DREQ message. Refer to [9] for procedures on how to forward
a DREP message.
6. Security Considerations
TBD
7. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[2] Awduche, D. O., Berger, L., Gan, D.-H., Li, T., Swallow, G.,
Srinivasan, V., "Extensions to RSVP for LSP Tunnels", Work in
Progress (Internet Draft), draft-ietf-mpls-rsvp-lsp-tunnel-06.txt,
July 2000.
[3] Aboul-Magd, O., Aparicio, O., Barry, R., Bernstein, G., Jain,
R., Jia, L., Dulepet, R., Lazer, M., Yates, J., Pendarakis, D.,
Rajagopalan, B., Rennison, R., Xu, Y., Xue, Y., Yu, J. and Zhang,
Z., "Signaling Requirements at the Optical UNI", Work in Progress
(Internet Draft), July 2000.
[4] Ashwood-Smith, P., Fan, Y., Banerjee, A., Drake, J., Lang, J.,
Berger, L., Bernstein, G., Kompella, K., Mannie, E., Rajagopalan,
B., Saha, S., Tang, Z., Rekhter, Y. and Sharma, V., "Generalized
MPLS - Signaling Functional Description", Work in Progress
(Internet Draft), draft-ashwood-generalized-mpls-signaling-00.txt,
June 2000.
Gray, et al Page 07
[5] Lang, J.P., Mitra, K., Drake, J., Kompella, K., Rekhter, Y.,
Saha, D., Berger, L., Basak, D., and Sandick, H., "Link Management
Protocol (LMP)", Work in Progress (Internet Draft),
draft-lang-mpls-lmp-01.txt, July 2000.
[6] Kompella, K., Rekhter, Y., Banerjee, A., Drake, J., Bernstein,
G., Fedyk, D., Mannie, E., Saha, D., and Sharma, V., "OSPF
Extensions in Support of MPL(ambda)S", Work in Progress (Internet
Draft), draft-kompella-ospf-ompls-extensions-00.txt, July 2000.
[7] Kompella, K., Rekhter, Y., Banerjee, A., Drake, J., Bernstein,
G., Fedyk, D., Mannie, E., Saha, D., and Sharma, V., "IS-IS
Extensions in Support of MPL(ambda)S", Work in Progress (Internet
Draft), draft-kompella-ospf-ompls-extensions-00.txt, July 2000.
[8] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119 (BCP 14), March 1997.
[9] Terzis, A., etal., "RSVP Diagnostic Messages", RFC 2745,
January 2000.
[10] Berger, L. etal., "RSVP Refresh Overhead Reduction Extensions",
Work in Progress (Internet Draft), June 2000.
[11] Kompella, K. etal., "Link Bundling in MPLS Traffic Engineering",
Work in Progress (Internet Draft), July 2000.
[12] Kompella, K. etal., "Traffic Engineering with Unnumbered Links",
Work in Progress (Internet Draft), July 2000.
8. Acknowledgments
TBD
9. Author's Addresses
Eric Gray
Zaffire, Inc.
2630 Orchard Parkway
San Jose, CA 95134
Email: egray@zaffire.com
Fong Liaw
Zaffire, Inc.
2630 Orchard Parkway
San Jose, CA 95134
Email: fliaw@zaffire.com
John Yu
Zaffire, Inc.
2630 Orchard Parkway
San Jose, CA 95134
Email: jzyu@zaffire.com
Gray, et al Page 08
Jonathan Lang
Calient Networks, Inc.
25 Castilian
Goleta, CA 93117
Email: jplang@calient.net
John Drake
Calient Networks, Inc.
25 Castilian
Goleta, CA 93117
Email: jdrake@calient.net
George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Email: swallow@cisco.com
Yakov Rekhter
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Email: yakov@cisco.com
Kireeti Kompella
Juniper Networks, Inc.
385 Ravendale Drive
Mountain View, CA 94043
Email: kireeti@juniper.net
Bala Rajagopolan
Tellium, Inc.
2 Crescent Place
Ocean Port, NJ 07757
Email: braja@tellium.com
Raj Jain
Nayna Networks, Inc.
157 Topaz Street
Milpitas, CA 95035
Email: raj@nayna.com
Osama Aboul-Magd
Nortel Networks
PO Box 3511, Station C
Ottawa, Ontario, Canada K1Y-4H7
Email: osmama@nortelnetworks.com
Greg Bernstein
Ciena Corporation, Core Switching Division
10201 Bubb Road
Cupertino, CA 95014
Email: greg@ciena.com
Gray, et al Page 09
Zhengsheng Zhang
Sorrento Networks
9990 Mesa Rim Road
San Diego, CA 92121
Email: zzhang@sorrentonet.com
Gray, et al Page 10