Networking Working Group
   Internet Draft                                          Anca Zamfir,
                                                              Zafar Ali
   Document: draft-zamfir-explicit-resource-        Cisco Systems, Inc.
   control-bundle-01.txt
   Expires: November 2003                                      May 2003


             Explicit Resource Control over GMPLS Link Bundles
           draft-zamfir-explicit-resource-control-bundle-01.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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 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

   Explicit label/ resource control using the Label ERO and Label RRO
   subobjects is defined in [RFC 3471] and [RFC 3473]. However, when TE
   links are bundled, identification of label resource is not enough for
   the purpose of explicit resource control. Specifically, when link
   bundling [GMPLS-BUNDLE] is used, resource identification requires
   mechanisms to specify the component link identifier, along the TE
   link identifier and Label. This draft defines the extensions to RSVP-
   TE [RFC2119, RFC3209] to specify component link identifiers for
   explicit resource control and recording over GMPLS link bundles.

Conventions used in this document



 Zamfir, A., Ali, Z.                                          [Page 1]


      draft-zamfir-explicit-resource-control-bundle-01.txt    May 2003



      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
   [RFC2119].

Sub-IP ID Summary

   (This section to be removed before publication.)

   SUMMARY

      This document specifies extensions and mechanisms to RSVP-TE to
   provide explicit resource control over GMPLS Link Bundles.

   WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK?

      This work fits in the MPLS box.

   WHY IS IT TARGETED AT THIS WG?

      This draft is targeted at this WG, because this it specifies
   extensions to RSVP-TE signaling protocol for explicit resource
   control over GMPLS Link Bundles [GMPLS-BUNDLE].

   RELATED REFERENCES

   Please refer to the reference section.




Table of Contents

   1. Terminology....................................................3
   2. Explicit Resource Control......................................3
   3. Signaling Component Interface Identifier in ERO................4
      3.1 Processing of Component Interface Identifier ERO Subobject.5
   4. LSP Resource Recording.........................................6
      4.1 Component Interface Identifier RRO subobject...............7
      4.2 Processing of Component Interface identifier RRO Subobject.8
   5. Forward Compatibility Note.....................................8
   6. Security Considerations........................................8
   References........................................................9
   Author's Addresses................................................9






Zamfir, A., Ali, Z.                                           [Page 2]


      draft-zamfir-explicit-resource-control-bundle-01.txt    May 2003



1.  Terminology

   TE Link - Unless specified otherwise, it refers to a bundled Traffic
   Engineering link as defined in [GMPLS-BUNDLE]. Furthermore, the terms
   TE Link and bundled TE Link are used interchangeably in this draft.

   Component Interface - Refers to one of the component links in a TE
   link.

   Component Interface Identifier - Refers to an ID used to uniquely
   identify a component link within a TE link.

2.  Explicit Resource Control

      In classical MPLS that deals with unbundled packet switch capable
   TE Links, one of the types of resources that an LSP originator can
   control is the TE Link interfaces used by the LSP. This is done by
   the use of an explicit route, i.e., ERO Object. Also, there are
   applications where LSP initiator wishes to select resources on a
   given TE Link [RFC 3471]. An example where such a mechanism is
   desirable is when there are two LSPs to be "spliced" together, i.e.,
   where the tail of the first LSP is to be "spliced" into the head of
   the second LSP. Label ERO subobject is defined in [RFC 3473] for this
   purpose. Similarly, for uni-directional LSPs the Label RRO subobject
   is defined in [RFC3209] and is extended for bi-directional LSP in
   [RFC 3471], [RFC 3473].
      Link Bundling introduced by [GMPLS-BUNDLE], is used to improve
   routing scalability by reducing the amount of TE related information
   that needs to be flooded and handled by IGP in a TE network. This is
   accomplished by aggregating and abstracting the TE Link resource. In
   some cases the complete resource identification is left as a local
   decision. However, as described above there are cases when it is
   desirable for a non-local (e.g., LSP Head) node to identify
   completely or partially the LSP resources.
      When link bundling is used to aggregate multiple component links
   into a TE link, label is not the only resource over TE link that
   needs to be identified. In other words, the TE Link and the Label
   specified in the ERO/ RRO objects are not enough to completely
   identify the resource. For the bundled TE link case, in order to
   fully specify the resources on a link for a given LSP, the component
   link needs to be specified along with the label. In the case of bi-
   directional LSPs both upstream and downstream triplets may be
   specified. In short, explicit resource control over a bundled TE link
   also requires ability to specify a component link within the TE link.
      This draft defines extensions to and describes the use of RSVP-TE
   [RFC2119, RFC3209, RFC3471, RFC3473] to specify the component link
   identifier for explicit resource control over GMPLS link bundles.
   Specifically, in this draft, component interface identifier ERO and


Zamfir, A., Ali, Z.                                           [Page 3]


      draft-zamfir-explicit-resource-control-bundle-01.txt    May 2003


   RRO subobjects are defined to complement their Label ERO and RRO
   counterparts for the cases where upstream and downstream directions
   of an LSP use different component links. Furthermore, procedures for
   processing component interface identifier ERO and RRO subobjects and
   how they can co-exist with the Label ERO and RRO subobjects are
   specified.


3.  Signaling Component Interface Identifier in ERO

      A new OPTIONAL subobject of the Explicit Route Object (ERO) is
   used to specify component interface identifier of a bundled TE Link.
   This subobject has the following format:

      Figure 1: Component Interface Identifier ERO subobject

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |L|    Type     |     Length    |U|   Reserved (MUST be zero)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  IPv4, IPv6 or unnumbered Component Interface Identifier      |
      |                            . . .                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         L: 1 bit

            This bit must be set to 0.

         Type

            10 (TBD) Component Interface identifier IPv4
            11 (TBD) Component Interface identifier Unnumbered
            12 (TBD) Component Interface identifier IPv6

         Length

             The Length contains the total length of the subobject in
             bytes, including the Type and Length fields. The Length is
             8 bytes for the Component Interface identifier types: IPv4
             and Component Interface identifier Unnumbered. For
             Component Interface identifier IPv6 type of sub-object,
             the length field is 20 bytes.


         U: 1 bit
             This bit indicates the direction of the component
             interface.  It is 0 for the downstream interface.  It is
             set to 1 for the upstream interface and is only used for


Zamfir, A., Ali, Z.                                           [Page 4]


      draft-zamfir-explicit-resource-control-bundle-01.txt    May 2003


             bi-directional LSPs.


3.1  Processing of Component Interface Identifier ERO Subobject

    The Component Interface Identifier ERO subobject follows a subobject
   containing the IP address, or the link identifier [RFC3477],
   associated with the TE link on which it is to be used. It is used to
   identify the component of a bundled TE Link.

      The following SHOULD result in "Bad EXPLICIT_ROUTE object" error
   being sent upstream by a node processing an ERO that contains the
   Component Interface ID sub-object:

      o The first component interface identifier subobject is not
      preceded by a sub-object containing an IP address, or an
      interface identifier [RFC3477], associated with a TE link.
      o The Component Interface Identifier ERO subobject follows a
      subobject that has the L-bit set.
      o On unidirectional LSP setup, there is a Component Interface
      Identifier ERO subobject with the U-bit set.
      o Two Component Interface Identifier ERO subobjects with the same
      U-bit values exist.

      If a node supports the component interface identifier subobject,
   it must check if it represents a component interface in the bundled
   TE Link specified in the preceding subobject that contains the IP
   address or interface identifier of the TE Link. If the content of the
   component interface identifier subobject does not match a component
   interface in the TE link, a "Bad EXPLICIT_ROUTE object" error SHOULD
   be reported as "Routing Problem" (error code 24).
      If U-bit of the subobject being examined is cleared (0) and the
   upstream interface specified in this subobject is acceptable, then
   the value of the upstream component interface is copied in the TLV of
   the IF_ID HOP object [RFC 3471] and the local decision normally used
   to select the upstream component link is bypassed. If this interface
   is not acceptable, a "Bad EXPLICIT_ROUTE object" error SHOULD be
   reported as "Routing Problem" (error code 24).

      If the U-bit of the subobject being examined is set (1), then the
   value represents the component interface to be used for upstream
   traffic associated with the bidirectional LSP.  Again, if this
   interface is not acceptable or if the request is not one for a
   bidirectional LSP, then a "Bad EXPLICIT_ROUTE object" error SHOULD be
   reported as "Routing Problem" (error code 24).  Otherwise, the
   component interface IP address/ identifier is copied into a TLV sub-
   object as part of the IF_ID HOP.




Zamfir, A., Ali, Z.                                           [Page 5]


      draft-zamfir-explicit-resource-control-bundle-01.txt    May 2003


      The IF_ID HOP object constructed as above MUST be included in the
   corresponding outgoing Path message.

      Note that, associated with a TE Link sub-object in the ERO, either
   the upstream component interface or the downstream component
   interface or both may be specified. As specified in [GMPLS-BUNDLE]
   there is no relationship between the TE Link type (numbered or
   unnumbered) and the Link type of any one of its components.

      The component interface identifier ERO subobject is optional.
   Similarly, presence of the Label ERO sub-objects is not mandatory
   [RFC 3471], [RFC 3473]. Furthermore, component interface identifier
   ERO subobject and Label ERO subobject may be included in the ERO
   independently of each other. When both sub-objects are absent, a node
   may select any appropriate component link within the TE link and any
   label on the selected component link. If only the Label subobject is
   present for a bundled link, then the selection of the component link
   within the bundle is a local decision and the node may select any
   appropriate component link, which can assume the label specified in
   the Label ERO. Similarly, when only the component interface
   identifier ERO subobject is present, a node MUST select the component
   interface specified in the ERO and may select any appropriate label
   value at the specified component link. In the case where both
   component interface identifier ERO subobject and Label ERO subobject
   are present, the node MUST select the specified component link and
   the specified label value on that component link. When both component
   interface identifier ERO subobject and Label ERO subobject are
   present, they may appear in any relative order to each other but they
   MUST appear after the TE Link sub-object that they refer to.

      After processing, the component interface identifier subobjects
   are removed from the ERO.

      Inferred from above, the interface subobject should never be the
   first subobject in a newly received message.  If the component
   interface subobject is the first subobject in a received ERO, then it
   SHOULD be treated as a "Bad strict node" error.

      Information to construct the Component Interface ERO subobject may
   come from the same mean used to populate the label ERO subobject.
   Procedures by which an LSR at the head-end of an LSP obtains the
   information needed to construct the Component Interface subobject are
   outside the scope of this document. However, such information
   typically comes from the configuration data.

4.  LSP Resource Recording

      This refers to the ability to record the resources used by an LSP.
   The procedure for unbundled TE links is described in [RFC3209]. For


Zamfir, A., Ali, Z.                                           [Page 6]


      draft-zamfir-explicit-resource-control-bundle-01.txt    May 2003


   the purpose of recording LSP resources used over bundled TE Links,
   the Component Interface Identifier RRO sub-object is introduced.
   Since Labels do not completely identify the LSP resources over
   bundled links, Label Recording request is interpreted as Resource
   Recording request when bundled links are involved.

4.1  Component Interface Identifier RRO subobject

      A new subobject of the Record Route Object (RRO) is used to record
   component interface identifier of a (bundled) TE Link. This subobject
   has the following format:

      Figure 2: Component Interface Identifier RRO subobject

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |L|    Type     |     Length    |U| Reserved  (must be zero)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Component Interface Identifier               |
      |                            . . .                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       0                   1                   2                   3

           L: 1 bit

            This bit must be set to 0.


         Type

            10 (TBD) Component Interface identifier IPv4
            11 (TBD) Component Interface identifier Unnumbered
            12 (TBD) Component Interface identifier IPv6

         Length

            The Length contains the total length of the subobject in
            bytes, including the Type and Length fields. The Length is
            8 bytes for the Component Interface identifier IPv4 and
            Component Interface identifier Unnumbered types. For
            Component Interface identifier IPv6 type of sub-object, the
            length field is 20 bytes.

         U: 1 bit

            This bit indicates the direction of the component
            interface.  It is 0 for the downstream interface.  It is


Zamfir, A., Ali, Z.                                           [Page 7]


      draft-zamfir-explicit-resource-control-bundle-01.txt    May 2003


            set to 1 for the upstream interface and is only used for
            bi-directional LSPs.

4.2   Processing of Component Interface identifier RRO Subobject

      If a node desires resource recording, then it sets the Label
   Recording flag in SESSION_ATTRIBUTE object as specified in [RFC3209].
   In other words, when a node desires label recording, it will also
   receive the component interface sub-objects in the RRO for the
   bundled links from the nodes that implement this extension. When the
   Label Recording flag in SESSION_ATTRIBUTE object is set and the
   outgoing TE Link is a bundled link, nodes doing route recording
   SHOULD include a Component Interface subobject along with the Label
   subobject. The Component Interface Record subobject is pushed onto
   the RECORD_ROUTE object prior to pushing on the node's IP address. A
   node MUST NOT push on a Component Interface Record subobject without
   also pushing on the IP address or unnumbered Interface Id subobject
   that identifies the TE Link.

      When component interfaces are recorded for bi-directional LSPs,
   component interface RRO subobjects for both downstream and upstream
   interfaces MUST be included.

5.  Forward Compatibility Note

      The extensions specified in this draft do not affect the
   processing of the ERO, RRO at nodes that do not support them. A node
   that receives an ERO that contains a Component Link ID subobject
   SHOULD send "Bad EXPLICIT_ROUTE object" if it does not implement this
   subobject. A node that does not support the Component Interface RRO
   subobject but that does support Label subobject SHOULD only insert
   the Label subobject in the RRO as per [RFC3471] and [RFC3473].
   As per [RFC3209], Section 4.4.5, a non-compliant node that receives
   an RRO that contains Component Interface Identifier sub-objects
   should ignore and pass them on.

6.  Security Considerations

     This document does not introduce new security issues. The security
   considerations pertaining to the original RSVP protocol [RFC2205]
   remain relevant.










Zamfir, A., Ali, Z.                                           [Page 8]


         draft-zamfir-explicit-resource-control-bundle-00.txt May 2003


References


   [RFC2205] " Resource ReSerVation Protocol (RSVP) - Version 1,
      Functional Specification", RFC 2205, Braden, et al, September
      1997.
   [RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et al,
   RFC 3209, December 2001.
   [GMPLS-BUNDLE] "Link Bundling in MPLS Traffic Engineering", draft-
      ietf-mpls-bundle-04.txt, K. Kompella, et al, January 2003.
   [RFC3471] Generalized Multi-Protocol Label Switching (GMPLS)
      Signaling Functional Description, RFC 3471, L. Berger, et al,
      January 2003.
   [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS)
      Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-
      TE) Extensions", RFC 3471, L. Berger, et al, January 2003.
   [RFC3477] "Signaling Unnumbered Links in Resource ReSerVation
      Protocol - Traffic Engineering (RSVP-TE) ", RFC 3477, K. Kompella,
      Y. Rekhter, January 2003.
   [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels",
      RFC 2119, S. Bradner, March 1997.


Author's Addresses

   Anca Zamfir
   Cisco Systems Inc.
   2000 Innovation Dr.,
   Kanata, Ontario, K2K 3E8
   Canada.
   Phone: (613)-254-3484
   Email: ancaz@cisco.com

   Zafar Ali
   Cisco Systems Inc.
   100 South Main St. #200
   Ann Arbor, MI 48104
   USA.
   Phone: (734) 276-2459
   Email: zali@cisco.com










Zamfir, A., Ali, Z.
[Page 9]