[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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