[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

   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:

     <ACK message> ::= <Common Header> [ <INTEGRITY> ]
               <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>
               [ [ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK> ] ... ]

   3.1.2 Hello Message

   Hello message is for node failure detection. Hello message is
   optional. It has the following format:

     <Hello message> ::= <Common Header> [ <INTEGRITY> ]
               [ [ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK> ] ... ]
               <HELLO>

   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]):

     <Notify message> ::= <Common Header> [<INTEGRITY>] <MESSAGE_ID>
                    <ERROR_SPEC> <notify session list>
     <notify session list> ::==
                    [<notify session list>] <notify session>
     <notify session> ::== <SESSION> [<POLICY_DATA>...]

   Yu, et al.                                                [Page 11]


                  draft-yu-mpls-rsvp-oif-uni-00.txt     November 2000

                     <sender descriptor>

   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:

     <Path Message> ::=
               <Common Header>
               [ <INTEGRITY> ]
               [ [ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK> ] ... ]
               <MESSAGE_ID>
               <SESSION> <RSVP_HOP>
               <TIME_VALUES>
               [ <EXPLICIT ROUTE> ]
               <GENERALIZED LABEL_REQUEST>
               [ <LABEL SET> ]
               [ <SESSION_ATTRIBUTE> ]
               [ <NOTIFY_REQUEST> ]
               [ <POLICY_DATA> ... ]
               <sender descriptor>

   The format of the sender descriptor for unidirectional lightpath is:

     <sender descriptor> ::=
               <SENDER_TEMPLATE> <SENDER TSPEC>
               [ <RECORD_ROUTE> ]
               [ <DOWNSTREAM_COMPONENT_INTERFACE_ID> ]
               [ <SUGGESTED LABEL> ]

   The format of the sender descriptor for bi-directional lightpath is:

         <sender descriptor> ::=
               <SENDER_TEMPLATE> <SENDER TSPEC>
               [ <RECORD_ROUTE> ]
               [ <DOWNSTREAM_COMPONENT_INTERFACE_ID> ]
               [ <SUGGESTED LABEL> ]
               [ <UPSTREAM_COMPONENT_INTERFACE_ID> ]
               <UPSTREAM LABEL>
   3.1.5 PathErr Message

   The PathErr Messages are used for error report and lightpath deletion
   from the network. The format of an O-UNI PathErr Message is shown as
   follows:

     <PathErr message> ::= <Common Header> [ <INTEGRITY> ]
               [ [ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK> ] ... ]
               <MESSAGE_ID>
               <SESSION>

   Yu, et al.                                                [Page 12]


                  draft-yu-mpls-rsvp-oif-uni-00.txt     November 2000

               <ERROR_SPEC>
               [ <sender description> ]

   3.1.6 PathTear Message

   The PathTear messages are used for lightpath deletion from the
   sender. The format of an O-UNI PathTear Message is shown as follows:

     <PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
               [ [ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK> ] ... ]
               <MESSAGE_ID>
               <SESSION> <RSVP HOP>
               [ <sender descriptor> ]

     <sender descriptor> ::= (see earlier definition)

   3.1.7 Resv Message

   The Resv messages are used for lightpath creation and modification.
   The format for an O-UNI Resv Message is as shown as follows:

   <Resv Message> ::= <Common Header> [ <INTEGRITY> ]
               [ [ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK> ] ... ]
               <MESSAGE_ID>
               <SESSION>  <RSVP_HOP>
               <TIME_VALUES>
               [ <RESV_CONFIRM> ]
               [ <NOTIFY_REQUEST> ]
               [<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.1.8 ResvConf Message

   The ResvConf messages are sent downstream from the source to
   acknowledge the reservation upon receiving the Resv message upstream.
   Specifically, in UNI 1.0, the ResvConf messages are sent from the
   ingress (source) UNI-C to ingress UNI-N, and from egress UNI-N to the

   Yu, et al.                                                [Page 13]


                  draft-yu-mpls-rsvp-oif-uni-00.txt     November 2000

   egress UNI-C across the ingress and egress UNIs. The format of an O-
   UNI ResvConf Message is shown as follows:

     <ResvConf message> ::= <Common Header> [ <INTEGRITY> ]
               [ [ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK> ] ... ]
               <MESSAGE_ID>
               <SESSION> <ERROR_SPEC>
               <RESV_CONFIRM>
               <STYLE> <flow descriptor list>

     <flow descriptor list> ::= (see earlier definition)

   3.1.9 ResvErr Message

   The ResvErr messages are used for error report. The format of an O-
   UNI ResvErr Message is shown as follows:

     <ResvErr message> ::= <Common Header> [ <INTEGRITY> ]
               [ [ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK> ] ... ]
               <MESSAGE_ID>
               <SESSION> <RSVP_HOP>
               <ERROR_SPEC>
               [ <POLICY_DATA> ... ]
               <STYLE> <flow error description>

   3.1.10 ResvTear Message

   The ResvTear messages are used for lightpath deletion from the
   receiver. The format of an O-UNI ResvTear Message is shown as
   follows:

     <ResvTear Message> ::=
               <Common Header> [ <INTEGRITY> ]
               [ [ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK> ] ... ]
               <MESSAGE_ID>
     <SESSION> <RSVP HOP>
               [ <SCOPE> ] <STYLE>
               <flow description list>

     <flow description list> ::= (see earlier list)

   3.1.11 Srefresh Message

   The Srefresh messages are used for lightpath status enquiry. The
   format of an O-UNI Srefresh Message is shown below:

     <Srefresh message> ::= <Common Header>  [ <INTEGRITY> ]
               [ [ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK> ] ... ]
               [ <MESSAGE_ID> ]
               <srefresh list>
               <srefresh list> ::= <MESSAGE_ID_LIST>
               [ <srefrsh list> ]


   Yu, et al.                                                [Page 14]


                  draft-yu-mpls-rsvp-oif-uni-00.txt     November 2000

   3.2 O-UNI RSVP objects format

   This section serves as a placeholder for O-UNI RSVP objects.

   3.2.1 Sender Template Object

   LSP_TUNNEL_IPv4 Sender Template Object [2] has the following format:

         Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv4 C-Type = 7
     0                   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   IPv4 tunnel sender address                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  MUST be zero                 |            LSP ID             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 tunnel sender address is the IPv4 address for a sender node. LSP
   ID is a 16-bit identifier used in the SENDER_TEMPLATE  and  the
   FILTER_SPEC  that  MAY  be  changed  to allow a sender to share
   resources with itself. LSP_TUNNEL_IPv6 Sender Template Object [2] has
   the following format:

         Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv6 C_Type = 8
     0                   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
     | +                                                               +
     |                   IPv6 tunnel sender address                  | +
     + |                            (16 bytes)                         |
     +                                                               + |
     | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  MUST be zero                 |            LSP ID             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 tunnel sender address is the IPv6 address for a sender node. LSP
   ID a  16-bit  identifier  used  in  the  SENDER_TEMPLATE  and  the
   FILTER_SPEC  that  MAY  be  changed  to allow a sender to share
   resources with itself to perform "make-before-break".

   3.2.2 Session Object

   LSP_TUNNEL_IPv4 Session Object [2] has the following format:

         Class = SESSION, LSP_TUNNEL_IPv4 C_Type = 7
     0                   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   IPv4 tunnel end point address               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  MUST be zero                 |      Tunnel ID                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Yu, et al.                                                [Page 15]


                  draft-yu-mpls-rsvp-oif-uni-00.txt     November 2000

     |                       Extended Tunnel ID                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 tunnel end point address is the IPv4 address of the egress node
   for the tunnel. Tunnel ID a 16-bit identifier used in the SESSION
   that  remains  constant over the life of the tunnel. Extended Tunnel
   ID is a 32-bit identifier used in the SESSION that remains  constant
   over  the  life  of  the  tunnel.  Extended Tunnel ID MUST be set to
   the source IP address or a pre-assigned lightpath identifier of a
   lightpath. This will uniquely identify a lightpath.
   LSP_TUNNEL_IPv6 Session Object [2] has the following format:

         Class = SESSION, LSP_TUNNEL_IPv6 C_Type = 8
     0                   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                   IPv6 tunnel end point address               |
     +                                                               +
     |                            (16 bytes)                         |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  MUST be zero                 |      Tunnel ID                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                       Extended Tunnel ID                      |
     +                                                               +
     |                            (16 bytes)                         |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 tunnel end point address is the IPv6 address of the egress node
   for the tunnel. Tunnel ID is a 16-bit identifier used in the SESSION
   that  remains  constant over the life of the tunnel. Extended Tunnel
   ID a 16-byte identifier used in the SESSION that remains constant
   over the life of the tunnel.  Extended Tunnel ID MUST be set to the
   source IP address of a lightpath. This will uniquely identify a
   lightpath in source and destination user node.

   3.2.3 Session Attribute Object

   The Session  Attribute  class  is  207 [2].  Two C_Types  are
   defined, LSP_TUNNEL, C-Type = 7 and  LSP_TUNNEL_RA,C-Type =  1.   The
   LSP_TUNNEL_RA C-Type includes all the same fields as the  LSP_TUNNEL
   C-Type.   Additionally it carries resource affinity information.  The
   formats are as follows:

   3.2.3.1 Format without resource affinities

   Yu, et al.                                                [Page 16]


                  draft-yu-mpls-rsvp-oif-uni-00.txt     November 2000

         SESSION_ATTRIBUTE class = 207, LSP_TUNNEL C-Type = 7
     0                   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Setup Prio  | Holding Prio  |     Flags     |  Name Length  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //          Session Name      (NULL padded display string)    //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  - Setup Priority is the priority of the session with respect to
     taking  resources, in  the  range of 0 to 7.  The value 0 is the
     highest priority. The Setup Priority is used in deciding whether
     this session MAY preempt another session.
  - Holding Priority the priority of the session with respect to
     holding  resources, in  the  range of 0 to 7.  The value 0 is the
     highest priority. Holding Priority is used in deciding whether this
     session MAY be preempted by another session.
  - Flags indicate Local protection desired, or Label recording
     desired, or SE Style desired.
  - Name Length is the length of the display string before padding, in
     bytes.
  - Session Name is null padded string of characters.

   3.2.3.2 Format with resource affinities

          SESSION_ATTRIBUTE class = 207, LSP_TUNNEL_RA C-Type = 1
     0                   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Exclude-any                                                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Include-any                                                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Include-all                                                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Setup Prio  | Holding Prio  |     Flags     |  Name Length  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //          Session Name      (NULL padded display string)     //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  - Exclude-any represents a  set  of  attribute  filters associated
     with   a  tunnel  any  of  which  renders  a  link unacceptable.
  - Include-any represents  a  set  of  attribute  filters  associated
     with a tunnel any of which renders a link acceptable (with respect
     to this test).
  - Include-all represents a set of attribute filters associated with a
     tunnel all of which MUST be present for a link to be acceptable
     (with respect to this test).

   Both the LSP_TUNEL or LSP_TUNNEL_RA subobjects SHALL be supported
   over the O-UNI. The usage of SESSION_ATTRIBUTE object in an O-UNI
   interface is as follows:

   Yu, et al.                                                [Page 17]


                  draft-yu-mpls-rsvp-oif-uni-00.txt     November 2000

  - The setup priority field indicates a lightpathÆs service priority
     [3] during signaling.
  - The holding priority field serves the purpose to indicate
     restoration priority [3].
  - The Exclude-any, Include-any, and Include-all fields are used to
     indicate diverse lightpath and user-specified routing requirements
     [3] from user nodes.

   3.2.4 Lightpath_ID Object

   The Lightpath_ID object is used to uniquely determine a lightpath
   within the optical network. Lightpath_ID object has the following
   format:

         Class = Lightpath_ID Class, C_Type = 1
     0                   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | IPv4 source address                                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | IPv4 destination address                                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Lightpath number                                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Lightpath number continue                                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


  - IPv4 source address: This is the address (32 bits) for the source
     UNI-C who originates the lightpath.
  - IPv4 destination address: This is the address (32 bits) for the
     destination UNI-C who terminates the lightpath.
  - Ligthpath number: This is the unique identifier (64 bits) in the
     network to be associated with the lightpath.

   3.2.5 GENERALIZED LABEL Object

   The Generalized Label [4] extends the traditional Label Object in
   that it allows the representation of not only labels which travel in-
   band with associated data packets, but also labels which identify
   time-slots, wavelengths, or space division multiplexed positions.
   The format of a Generalized Label is [4]:

     0                   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Length             | Class Num (16)|   C_Type (2)  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Label                             |
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Yu, et al.                                                [Page 18]


                  draft-yu-mpls-rsvp-oif-uni-00.txt     November 2000

   Refer to [4] for detailed format for SONET/SDH label and
   port/wavelength label.

   3.2.6 GENERALIZED LABEL REQUEST Object

   GENERALIZED LABEL REQUEST object [4] is used to indicate a
   lightpathÆs bandwidth, diversion (protection) type, and framing type.
   Regarding support for diversion indication, this object specifies
   only the protection type. If explicit link inclusion or exclusion is
   desirable, SESSION ATRRIBUTE object SHALL be used.

   The format of a Generalized Label Request with SONET/SDH Label range
   is:

     0                   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Length                        | Class Num (19)|C_Type (5)[TBA]|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | LSP Enc. Type |Link Prot.Flags|             G-PID             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  RGT  | RT  |    Reserved   |              RNC                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  - LSP Encoding Type indicates the encoding of the LSP being
     requested.
  - Link Protection Flags indicate the desired protection level(s) for
     each link along the LSP.  Note that the flags are distinct from
     MPLS-level LSP protection. More than one bit MAY be set to indicate
     when multiple protection types are acceptable.  When multiple bits
     are set and multiple protection types are available, the choice of
     protection type is a local (policy) decision.
  - Generalized PID (G-PID) is an identifier of the payload carried by
     an LSP, i.e. an  identifier of the client layer of that LSP.  This
     MUST be interpreted according to the technology encoding type of
     the LSP and is used by the nodes at the endpoints of the LSP.
  - Requested Grouping Type (RGT) indicates the SDH/SONET type of
     grouping requested for the LSP, it is used to constraint the type
     of concatenation.
  - Requested Transparency (RT) indicates the type of SDH/SONET
     transparency ("emulation") requested for that LSP.
  - Requested Number of Components (RNC) indicates the number of
     identical SDH/SONET signal types that are requested to be
     concatenated or inverse multiplexed in that LSP, as specified in
     the previous field. In these cases, the bandwidth of each component
     of that concatenation/bundling is obtained by dividing the
     aggregate bandwidth by the number of components requested. It is
     assumed that all these components have identical characteristics.
     This field is set to zero if non-concatenation or bundling is
     requested.

   3.2.7 LABEL SET Object

   Yu, et al.                                                [Page 19]


                  draft-yu-mpls-rsvp-oif-uni-00.txt     November 2000

   The Label Set is used to limit the label choices of a downstream node
   to a set of acceptable labels.  This limitation applies on a per hop
   basis. LABEL SET object is used to specify the port and channel to be
   used by a lightpath at the source. The support of this object is
   optional. The format of a Label_Set is shown below and described in
   [4]:

     0                   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Length                      | Class Num (xx)|C_Type (xx)    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Reserved                    |      Type                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Subchannel                          |
     |                            ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   3.2.8 SUGGESTED LABEL Object

   The Suggested Label [4] is used to provide a downstream node with the
   upstream node's label preference.  This permits the upstream node to
   start configuring it's hardware with the proposed label before the
   label is communicated by the downstream node. SUGGESTED LABEL object
   is used by a user (network) node to suggest a label to a network
   (user) node. The specified label is a suggestion, and downstream node
   MAY select a different label in its Resv message.
   The format of a suggested label is identical to a generalized label.
   It is used in Path/REQUEST messages.  In RSVP the Suggested Label
   uses a new class number (TBD of form 10bbbbbb) and the C-type of the
   label being suggested.

   3.2.9 UPSTREAM LABEL Object

   For bi-directional LSPs, two labels MUST be allocated.  Bi-
   directional LSP setup is indicated by the presence of an Upstream
   Label in the REQUEST/Path message [4].  Lightpath is typical uni-
   directional. However, the directionality of some framing type is
   implied [17], e.g. SONET/SDH and G.E. is bi-directional. Therefore,
   when a Framing Type implies bi-directional lightpath, this object
   SHALL be included in the Path Message.

   An Upstream Label has the same format as the generalized label.  It
   uses a new class number (TBD of form 0bbbbbbb) and the C-type of the
   label being suggested.

   3.2.10 ERROR_SPEC Object

   ERROR_SPEC object has the following format [15]:

         o    IPv4 ERROR_SPEC object: Class = 6, C-Type = 1
          +-------------+-------------+-------------+-------------+
          |            IPv4 Error Node Address (4 bytes)           |
   Yu, et al.                                                [Page 20]


                  draft-yu-mpls-rsvp-oif-uni-00.txt     November 2000

          +-------------+-------------+-------------+-------------+
          |    Flags    |  Error Code |        Error Value        |
          +-------------+-------------+-------------+-------------+

         o    IPv6 ERROR_SPEC object: Class = 6, C-Type = 2
          +-------------+-------------+-------------+-------------+
          |                                                       |
          +                                                       +
          |                                                       |
          +          IPv6 Error Node Address (16 bytes)           +
          |                                                       |
          +                                                       +
          |                                                       |
          +-------------+-------------+-------------+-------------+
          |    Flags    |  Error Code |        Error Value        |
          +-------------+-------------+-------------+-------------+

  - Error Node Address is the IP address of the node in which the error
     was detected. This field MAY be set to zero if the address of the
     failed node is not known or its disclosure is not desirable.
  - Flags is used only for an ERROR_SPEC object in a ResvErr message.
     If it on, this flag indicates that there was, and still is, a
     reservation in place at the failure point, or indicates  that the
     FLOWSPEC that failed was strictly greater than the FLOWSPEC
     requested by this receiver.
  - Error Code is for error description.
  - Error Value contains additional information about the error.

   3.2.11 Filter Specification Object

   FILTER_SPEC [2] is used to identify the LSP, per RSVP-TE, required to
   identify the LSP in Resv.

   LSP_TUNNEL_IPv4 Filter Specification Object:

         Class = FILTER SPECIFICATION, LSP_TUNNEL_IPv4 C-Type = 7,

   and the format of the object is identical to the LSP_TUNNEL_IPv4
   SENDER_TEMPLATE object.

   LSP_TUNNEL_IPv6 Filter Specification Object:

         Class = FILTER SPECIFICATION, LSP_TUNNEL_IPv6 C_Type = 8.

   and the format of the object is identical to the LSP_TUNNEL_IPv6
   SENDER_TEMPLATE object.

   3.2.12 FLOWSPEC Object

   An OIF FLOWSPEC object MAY be defined and used to carry the peak
   bandwidth and the maximum propagation delay information and SHALL be
   used only if a limit on maximum delay propagation is applicable.

   Yu, et al.                                                [Page 21]


                  draft-yu-mpls-rsvp-oif-uni-00.txt     November 2000

        OIF_FLOWSPE object: Class = 9, C-Type = 0bbbbbbb.
   0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Bandwidth                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Delay                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  - Bandwidth is carried in 32-bit number in IEEE floating-point format
     (the unit is bytes per second).
  - Delay indicates the maximum delay the lightpath may experience.  It
     is expressed in 32 bit unsigned integer in unit of one microsecond.

   3.2.13 SENDER_TSPEC Object

   An OIF SENDER_TSPEC object MAY be defined and used to carry the peak
   bandwidth and the maximum propagation delay information and SHALL be
   used only if a limit on maximum delay propagation is applicable.

        OIF_SENDER_TSPEC object: Class = 12, C-Type = 0bbbbbbb.

   OIF_SENDER_TSPEC Object has the same format as OIF_FLOWSPEC Object.

   3.2.14 INTEGRITY Object

   The INTEGRITY Object [18] of an RSVP control message contains
   cryptographic data to authenticate the originating node and to verify
   the contents of an RSVP message.

         INTEGRITY Object: Class = 4, C-Type = 1

          +-------------+-------------+-------------+-------------+
          |    Flags    | 0 (Reserved)|                           |
          +-------------+-------------+                           +
          |                    Key Identifier                     |
          +-------------+-------------+-------------+-------------+
          |                    Sequence Number                    |
          |                                                       |
          +-------------+-------------+-------------+-------------+
          |                                                       |
          +                                                       +
          |                                                       |
          +                  Keyed Message Digest                 |
          |                                                       |
          +                                                       +
          |                                                       |
          +-------------+-------------+-------------+-------------+

   Refer to [18] for the detailed usage and code point.

   3.2.15 COMPONENT_INTERFACE_ID Object



   Yu, et al.                                                [Page 22]


                  draft-yu-mpls-rsvp-oif-uni-00.txt     November 2000

   The COMPONENT_INTERFACE_ID object classÆs length field is set to 8.
   The Class Num is TBD of form 0bbbbbbb.  The
   DOWNSTREAM_COMPONENT_INTERFACE_ID object, which has a C_Type of 1, is
   used to indicate the component interface to be used    for traffic
   flowing in the downstream direction.  The
   UPSTREAM_COMPONENT_INTERFACE_ID object, which has a C_Type of 2, is
   used to indicate the component interface to be used for traffic
   flowing in the upstream direction.  Both objects have the same format
   and carry a 16-bit Component Interface Identifier. The format of the
   objects is:

       0                   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Length             |Class Num (TBD)|  C_Type (1|2) |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Reserved               | Component Interface Identifier|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   3.2.16 MESSAGE_ID Object

   MESSAGE_ID object [10] has the following format:

         Class = MESSAGE_ID Class, C_Type = 1
     0                   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Flags         |                      Epoch                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Message_Identifier                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  - Flags indicate that the sender requests the receiver to send an
     acknowledgment for the message.
  - Epoch indicates when the Message_Identifier sequence has reset.
     SHOULD be randomly generated each time a node reboots or the RSVP
     agent is restarted.  The value SHOULD NOT be the same as was used
     when the node was last operational.  This value MUST NOT be changed
     during normal operation.
  - Message_Identifier: When combined with the message generator's IP
     address, the Message_Identifier field uniquely identifies a
     message.  The values placed in this field change incrementally and
     only decrease when the Epoch changes or when the value wraps.

   3.2.17 MESSAGE_ID_ACK Object

   MESSAGE_ID_ACK object [10] has the following format:

         Class = MESSAGE_ID_ACK Class, C_Type = 1
     0                   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Flags     |                      Epoch                      |

   Yu, et al.                                                [Page 23]


                  draft-yu-mpls-rsvp-oif-uni-00.txt     November 2000

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Message_Identifier                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  - Flags: No flags are currently defined.  This field MUST be zero on
     transmission and ignored on receipt.
  - Epoch: The Epoch field copied from the message being acknowledged.
  - Message_Identifier: The Message_Identifier field copied from the
     message being acknowledged.

   3.2.18 MESSAGE_ID_NAC Object

   MESSAGE_ID_NACK object [10]:

        Class = MESSAGE_ID_ACK Class, C_Type = 2

   It has the same format as the MESSAGE_ID_ACK object.

   3.2.19 MESSAGE_ID_LIST Object

   MESSAGE_ID_LIST object [10] has the following format:

         Class = MESSAGE_ID_LIST Class, C_Type = 1
     0                   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Flags       |                      Epoch                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                       Message_Identifier                    //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Message_Identifier                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  - Flags: No flags are currently defined.  This field MUST be zero on
     transmission and ignored on receipt.
  - Epoch: The Epoch field from the MESSAGE_ID object corresponding to
     the trigger message that advertised the state being refreshed.
  - Message_Identifier: The Message_Identifier field from the
     MESSAGE_ID object corresponding to the trigger message that
     advertised the state being refreshed.  One or more
     Message_Identifiers MAY be included.

   3.2.20 POLICY_DATA Class

   POLICY_DATA objects [16] contain policy information and are carried
   by RSVP messages. Policy_Data class MAY be used to convey Contract ID
   and User group ID as required by [3]. This specification does not
   mandate the support of specific Policy Data sub-objects, they are
   left to the network providers and vendors to decide.

   3.2.21 RSVP HOP Object


   Yu, et al.                                                [Page 24]


                  draft-yu-mpls-rsvp-oif-uni-00.txt     November 2000

   RSVP_HOP Carries the IP address of the RSVP-capable node that sent
   this message and a logical outgoing interface handle. It refers to a
   RSVP_HOP object as a PHOP ("previous hop") object for downstream
   messages or as a NHOP ("next hop") object for upstream messages [15].
   The RSVP_HOP object of each Path message contains the previous hop
   address, i.e., the IP address of the interface through which the Path
   message was most recently sent.

   When a node forwards a Path message out a logical outgoing interface,
   it includes in the message some encoding of the identity of logical
   outgoing interface, called the "logical interface handle", or LIH.
   For an O-UNI interface, the LIH MUST carry a control channelÆs
   identity over which the lightpath is to be established. The LIH value
   is carried in the RSVP_HOP object. The RSVP_HOP object has the
   following format [15]:

         o    IPv4 RSVP_HOP object: Class = 3, C-Type = 1
          +-------------+-------------+-------------+----------------+
          |                IPv6 Next/Previous Hop Address            |
          +-------------+-------------+-------------+----------------+
          |                   Logical Interface Handle           |
          +-------------+-------------+-------------+----------------+

         o    IPv6 RSVP_HOP object: Class = 3, C-Type = 2
          +-------------+-------------+-------------+----------------+
          |                                                          |
          +                                                          +
          |                                                          |
          +                IPv6 Next/Previous Hop Address            +
          |                                                          |
          +                                                          +
          |                                                          |
          +-------------+-------------+-------------+----------------+
          |                Logical Interface Handle                  |
          +-------------+-------------+-------------+----------------+

   This object carries the IP address of the interface through which the
   last RSVP-knowledgeable hop forwarded this message.  The LIH is used
   to distinguish logical outgoing interfaces.  A node receiving an LIH
   in a Path message saves its value and returns it in the HOP objects
   of subsequent Resv messages sent to the node that originated the LIH.
   LIH SHALL be set to ifindex value. It is used to identify an O-UNI
   when a non-directly connected signaling transport channel is used
   between the user and network node.

   3.2.22 TIME_VALUES Object

   The TIME_VALUES object [15] in an RSVP control message specifies the
   time period timer used for refreshing the state in this message. It
   indicates the refresh rate of a Path or Resv message that carries
   this object.

       TIME_VALUES Object: Class = 5, C-Type = 1
   Yu, et al.                                                [Page 25]


                  draft-yu-mpls-rsvp-oif-uni-00.txt     November 2000

          +-------------+-------------+-------------+-------------+
          |                   Refresh Period R                     |
          +-------------+-------------+-------------+-------------+

   Refresh Period is the refresh timeout period R used to generate this
   message, in milliseconds.

   3.2.23 Notify Request Object

   Notifications may be sent via the Notify message defined below.  The
   Notify Request object is used to request the generation of
   notifications.  Notifications, i.e., the sending of a Notify message,
   may be requested in both the upstream and downstream directions.
   The Notify Request Object [4] MAY be carried in Path or Resv message,
   see Section 7.  The NOTIFY_REQUEST class number is TBA (of form
   11bbbbbb).  The format of a Notify Request is:

     0                   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Length             | Class Num(TBD)|  C_Type (1)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    IPv4 Notify Node Address                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     IPv4 Notify Node Address: 32 bits, set to the IP address of the
     node that should be notified when generating an error message.

4.   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-07.txt,
   August 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-ietf-mpls-generialized-signaling-00.txt, October 2000.
   [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.

   Yu, et al.                                                [Page 26]


                  draft-yu-mpls-rsvp-oif-uni-00.txt     November 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-ietf-gmpls-extensions-00.txt, September 2000.
   [8]    Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119 (BCP 14), March 1997.
   [9]    Terzis, A., et al., "RSVP Diagnostic Messages", RFC 2745,
   January 2000.
   [10]   Berger, L. et al., "RSVP Refresh Overhead Reduction
   Extensions", work in progress, June 2000.
   [11]Kompella, K. et al., "Link Bundling in MPLS Traffic Engineering",
   work in progress, July 2000.
   [12]   Kompella, K. et al., "Traffic Engineering with Unnumbered
   Links", work in progress, Expire March 2001.
   [13]   Larry McAdams, Jennifer Yates, Krishna Bala, "User to Network
   Interface (UNI) Service Definition and Lightpath Attributes",
   OIF2000.061, September 2000.
   [14]   D. Pendarakis et al. ôSignaling Transport Mechanisms for UNI
   1.0ö, oif2000.xxx, Nov. 2000
   [15]   R. Braden, Ed., ôResource ReSerVation Protocol (RSVP) --
   Version 1 Functional Specificationö, RFC 2205, September 1997.
   [16]   S. Yadav, ôIdentity Representation for RSVPö, RFC 2752,
   January 2000.
   [17]   L. McAdams, ôUser to Network Interface Service Definition and
   Lightpath Attributesö, OIF2000.061, February 2000.
   [18]   F. Baker et al. ôRSVP Cryptographic Authenticationö,
   RFC 2747, January 2000.

   8. Acknowledgments

   TBD

   9. Author's Addresses

      John Yu
      Zaffire, Inc.
      2630 Orchard Parkway
      San Jose, CA 95134
      Email: jzyu@zaffire.com

      Fong Liaw
      Zaffire, Inc.
      2630 Orchard Parkway
      San Jose, CA 95134
      Email: fliaw@zaffire.com

      Eric Gray
      BrightWave Inc.
      16 Jacob Amsden Road,
      Westborough, MA, 01581
      ewgray@mindspring.com

      Jonathan Lang
   Yu, et al.                                                [Page 27]


                  draft-yu-mpls-rsvp-oif-uni-00.txt     November 2000

      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

      Greg Bernstein
      Ciena Corporation, Core Switching Division
      10201 Bubb Road
      Cupertino, CA 95014
      Email: greg@ciena.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

      Robert Rennison
      Laurel Networks, Inc.
      Email: robren@laurelnetworks.com

      Yangguang Xu
      Lucent Technology
      Email: xugy@lucent.com

      Raj Jain
      Nayna Networks, Inc.
      157 Topaz Street
      Milpitas, CA 95035
      Email: raj@nayna.com

      Zhengsheng Zhang
      Sorrento Networks
      9990 Mesa Rim Road
      San Diego, CA 92121
   Yu, et al.                                                [Page 28]


                  draft-yu-mpls-rsvp-oif-uni-00.txt     November 2000

      Email: zzhang@sorrentonet.com

      Dimitrios Pendarakis
      Tellium, Inc.
      2 Crescent Place
      Ocean Port, NJ 07757
      Email: dpendarakis@tellium.com

      Nooshin Komaee
      Tellium, Inc.
      2 Crescent Place
      Ocean Port, NJ 07757
      Email: nkomaee@tellium.com








































   Yu, et al.                                                [Page 29]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/