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

Versions: 00

CCAMP Working Group                                      Z. Ali (Cisco)
Internet Draft                           A. Farrel (Old Dog Consulting)
Category: Standards Track                    D. Papadimitriou (Alcatel)
                                               A. Satyanarayana (Movaz)
                                                      A. Zamfir (Cisco)

Expires: November 2004                                         May 2004


       Generalized Multi-Protocol Label Switching (GMPLS) RSVP-TE
         signaling using Bundled Traffic Engineering (TE) Links


         draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-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.  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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html



Abstract

   This document is a companion to the Generalized Multi-Protocol Label
   Switching (GMPLS) RSVP-TE signaling. It extends the TLV definitions
   of [RFC3471] to provide the means to identify component links of
   unnumbered link bundles within the IF_ID_RSVP_HOP and IF_ID
   ERROR_SPEC objects. It also defines the extensions to GMPLS RSVP-TE
   in support of component link identifiers for explicit resource
   control and recording over link bundles.






D.Papadimitriou (Editor) et al.                                      1

draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt        May 2004

1. Motivation

   Link bundling introduced in [BUNDLE] is used to improve routing
   scalability by reducing the amount of Traffic Engineering related
   information that needs to be flooded and handled by an IGP within an
   Autonomous System. This is accomplished by aggregating and
   abstracting the TE Link resource. GMPLS RSVP-TE [RFC3471, RFC3473]
   allows a bundle of Traffic Engineering links (TE links) to be
   represented as a single TE link bundle (a.k.a. bundled TE link). The
   constituting links of a TE link bundle are referred to as component
   TE links or simply component links.

   [RFC3477] defines how unnumbered links may be used in RSVP-TE.
   [RFC3471] and [RFC3473] define how unnumbered links can be
   identified within the IF_ID_RSVP_HOP and IF_ID ERROR_SPEC objects.
   Both numbered and unnumbered component link identifiers are
   supported. Moreover, [RFC3471] and [RFC3473] define how numbered and
   unnumbered component links of numbered TE link bundles may be
   identified within the IF_ID_RSVP_HOP and IF_ID ERROR_SPEC objects.
   However, there is no provision for identifying component links of
   unnumbered TE link bundles within the IF_ID RSVP_HOP and IF_ID
   ERROR_SPEC objects. This is required for completeness and to allow
   full functionality of GMPLS RSVP-TE. This document extends the TLV
   definitions of [RFC3471] to provide the means to identify component
   links of unnumbered TE link bundles within the IF_ID_RSVP_HOP and
   IF_ID ERROR_SPEC objects.

   GMPLS RSVP-TE [RFC3471, RFC3473] recognizes the value of specifying
   the link (interface) identifier both during LSP establishment for
   out-of-band signaling (IF_ID_RSVP_HOP object), and for error
   reporting (IF_ID ERROR_SPEC object). This is achieved using TLVs in
   these objects to specify the link (interface) identifier. Both
   numbered and unnumbered link (interface) identifiers are supported.
   Furthermore, GMPLS RSVP-TE [RFC3471, RFC3473] recognizes the value
   of specifying the component link (interface) identifier of a TE link
   bundle during LSP establishment (IF_ID_RSVP_HOP object), and for
   error reporting (IF_ID ERROR_SPEC object). This is achieved using
   TLVs in these objects to specify the component link (interface)
   identifier within a TE link (interface) identifier. However, only
   numbered and unnumbered component link (interface) identification
   within numbered TE link bundles is supported.

   In (G)MPLS, resource control and recording is performed by the use
   of an explicit route, i.e., EXPLICIT_ROUTE Object (ERO) and
   RECORD_ROUTE Object (RRO), respectively. In most scenarios the
   complete resource identification is left as a local decision.
   However, there are cases when it is desirable for a non-local (e.g.,
   LSP Head-end) node to identify completely or partially the LSP
   resources. Consequently, Label ERO (EXPLICIT_ROUTE Object) and RRO
   (RECORD_ROUTE Object) subobjects are defined in [RFC3473] to support
   Explicit Label Control and recording.

   When link bundling is used to aggregate multiple component links
   into a TE link bundle, the label is not the only resource that needs

D.Papadimitriou (Editor)                                             2

draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt        May 2004

   to be identified and recorded. In other words, the TE link bundle
   identifier and the label value 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 TE link
   bundle for a given LSP, the component link identifier needs to be
   specified along with the label. In the case of bi-directional LSPs
   both upstream and downstream information may be specified.
   Therefore, explicit resource control and recording over a TE link
   bundle also requires ability to specify a component link within the
   TE link bundle.

   This document defines extensions to and describes the use of RSVP-TE
   [RFC3209], [RFC3471], [RFC3473], and [RFC3477] to specify the
   component link identifier for resource recording and explicit
   resource control over TE link bundles. Specifically, it defines the
   component interface identifier ERO and RRO subobjects to complement
   their Label ERO and RRO counterparts. 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. The document also addresses identification of numbered
   and unnumbered component link (interface) within unnumbered TE link
   bundles.

2. Conventions used in this document:

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

   Moreover, the reader is assumed to be familiar with the terminology
   introduced in [GMPLS-ARCH], [RFC3471], [RFC3473], [RFC3477] and
   [BUNDLE]. The following abbreviations are used in this document:

3. Unbundled TE Link Identification

   TE links need to be identified in ERO, RRO, RSVP_HOP and
   ERROR_SPEC objects. When out-of-band signaling is used, [RFC3471]
   extends RSVP_HOP and ERROR_SPEC objects, to include TLVs to
   completely identify the TE links. These are the IF_ID RSVP_HOP and
   IF_ID ERROR_SPEC objects.

   A numbered unbundled TE link can be uniquely identified with the
   IPv4 address or the IPv6 address of the TE link. There are no
   additional formats required to those defined in [RFC3209] to
   identify numbered unbundled TE links in ERO and RRO objects. The
   IPv4 and IPv6 TLVs defined in [RFC3471] are used with IF_ID
   RSVP_HOP and IF_ID ERROR_SPEC objects to identify numbered
   unbundled TE links when out-of-band signaling is used.

   An unnumbered unbundled TE link can be uniquely identified by the
   tuple {IP Address, Interface ID}. [RFC3477] defines the Unnumbered
   Interface ID subobject to identify unnumbered unbundled TE links
   in ERO and RRO objects. The IF_INDEX TLV defined in [RFC3471] is
   used with the IF_ID RSVP_HOP and the IF_ID ERROR_SPEC objects to

D.Papadimitriou (Editor)                                             3

draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt        May 2004

   identify unnumbered unbundled TE links when out-of-band signaling
   is used.

   The following are the TLVs are defined in [RFC3471] to identify
   unbundled TE links.

   Type Length Format         Description
   ---- ------ ---------      -----------
    1      8   IPv4 Address   IPv4                (Interface address)
    2     20   IPv6 Address   IPv6                (Interface address)
    3     12   Compound       IF_INDEX            (Interface index)

4. Component and Bundled TE Link Identification

   If a TE link bundle is numbered, the tuple {IP Address, Component
   ID} is required to uniquely identify a component link in the TE
   link bundle. In this case, depending on the origin of value
   assigned to the IP Address either the tuple {Router Address,
   Component ID} or {TE Link Address, Component ID} is sufficient to
   uniquely identify an unnumbered component link in the TE link
   bundle. These tuples are respectively of Type 4, 5 and the newly
   defined Type 6, 7. [RFC3471] defines the following TLVs for
   Component ID identification IF_ID RSVP_HOP and IF_ID ERROR_SPEC
   objects.

   Type Length Format   Description
   ---- ------ ------   -----------
    4   12   Compound   COMPONENT_IF_DOWNSTREAM (Component interface)
    5   12   Compound   COMPONENT_IF_UPSTREAM   (Component interface)
    6   12   Compound   COMPONENT_IF_DOWNSTREAM (Component interface)
    7   12   Compound   COMPONENT_IF_UPSTREAM   (Component interface)

   If a TE link bundle is unnumbered, the tuple {IP Address, Bundle
   ID, Component ID} is required to uniquely identify a component
   link in the TE link bundle. In this case, two new TLVs are defined
   for use in the IF_ID RSVP_HOP object and in the IF_ID ERROR_SPEC
   Object to identify a component link in an unnumbered TE link
   bundle. Note that the Type values shown here are only suggested
   values - final values are TBD and to be determined by IETF
   consensus.

   Type Length Format   Description
   ---- ------ ------   -----------
    8   16   See below  UNUM_COMPONENT_IF_DOWN  (Component interface)
    9   16   See below  UNUM_COMPONENT_IF_UP    (Component interface)

   The formats of both the TLVs are the same, as defined below. Two
   new TLV types are defined. UNUM_COMPONENT_IF_DOWN is used to
   identify the downstream component link in an unnumbered TE link
   bundle. UNUM_COMPONENT_IF_UP is used to identify the upstream
   component link in an unnumbered TE link bundle.

   Note: [BUNDLE] and [RFC3477] assumes that identifying component
   link suffices to identify (bundle link, component link) for both

D.Papadimitriou (Editor)                                             4

draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt        May 2004

   numbered and unnumbered case. I.e., for unnumbered case, both
   component link identifiers and TE link identifiers comes from the
   same unit32 bit space.

4.1 TLV Definitions

   The new TLVs have a common format as shown below.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            IP Address                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Interface ID                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Component ID                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     IP Address: 32 bits

     Any IP address associated with the local node. This should be an
     IP address that has the highest availability on the node. This
     may match the Router Address value as advertised in TE LSAs by
     routing.

     Interface ID: 32 bits

     The identifier of the unnumbered bundled link. By definition,
     this is unique within the scope of the node identified by the IP
     Address field.

     Component ID: 32 bits

     The identifier of the component link in the unnumbered TE
     bundle, uniquely identified by the tuple {IP Address, Interface
     ID}. During LSP establishment, the special value 0xFFFFFFFF can
     be used to indicate the same label to be valid across all
     component links in the bundle identified by the {IP Address,
     Interface ID}.

5. Signaling Component TE Links 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 SHOULD NOT be used apart from (explicit) egress label
   control as defined in [EGRESS].

   This subobject has the following format:

   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

D.Papadimitriou (Editor)                                             5

draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt        May 2004

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |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 IPv6
            12 (TBD) Component Interface identifier Unnumbered

         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 bi-
            directional LSPs.

5.1 Processing of Component Interface Identifier ERO Subobject

   The Component Interface Identifier ERO subobject identifies the
   component of a bundled TE Link. This subobject MUST follow 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.

   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 IPv4 or IPv6 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.

D.Papadimitriou (Editor)                                             6

draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt        May 2004

      o) Two Component Interface Identifier ERO subobjects with the
         same U-bit values exist.

   If a node implements 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 the 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]. In this case, 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 RSVP_HOP object.

   The IF_ID RSVP_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 [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.
   Furthermore, component interface identifier ERO subobject and Label
   ERO subobject (see [RFC 3471] and [RFC 3473]) may be included in the
   ERO independently of each other. One of the following alternatives
   applies:
   o) 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.
   o) When the Label subobject is only 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.
   o) 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.
   o) When both component interface identifier ERO subobject and Label

D.Papadimitriou (Editor)                                             7

draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt        May 2004

      ERO subobject are present, the node MUST select the specified
      component link and the specified label value on that component
      link. When present, both subobjects 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.

   Note: 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.

6. Signaling Component TE Links in (IF_ID)_RSVP_HOP object

   This memo does not modify procedures for use of TLVs in the IF_ID
   RSVP_HOP object, defined in [RFC3471], [RFC3473] and [RFC3477]. The
   new TLVs can be used in the IF_ID RSVP_HOP object. The component ID
   values in TLV types 6 and 7 are values local to the upstream node.
   TLV type 6 is used with semantics similar to TLV type 4. TLV type 7
   is used with semantics similar to TLV type 5.

   When a component link part of a bundled TE Link fails and the LSP
   traffic is "automatically" moved to another component link. This
   must be followed not only by an IGP update on available resources
   for the bundle but also by a soft state resync at the two ends of
   the bundle (new states are on different interfaces, ideally without
   doing any "local" make-before-break i.e. no PathErr message
   exchange). Need to clearly differentiate this from span protection
   where a single link or component link includes physical protection.
   In the former case, the upstream node would change the IF_ID
   information for the LSP on the new Path it sends and the downstream
   node would update forwarding and protocol state. There would be no
   impact further up or downstream (unless component link recording was
   enabled in the RRO).

7. Reporting Component TE Links in RROs

   A new OPTIONAL 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:

   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

D.Papadimitriou (Editor)                                             8

draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt        May 2004

      |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 IPv6
            12 (TBD) Component Interface identifier Unnumbered

         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 set
            to 1 for the upstream interface and is only used for bi-
            directional LSPs.

7.1 Processing of Component Interface identifier RRO Subobject

   If a node desires component link recording, the "Component Link
   Recording desired" flag (value TBD) should be set in the
   LSP_ATTRIBUTES object, object that is defined in [RSVP-TE-
   ATTRIBUTE]. Another alternate is to use an available flag in the
   SESSION_ATTRIBUTE object [RFC3209]. The later makes the component
   link recording request similar to the label recording request. These
   alternatives need to be discussed with the CCAMP working group and
   close accordingly.

   Setting of "Component Link Recording desired" flag is independent of
   the Label Recording flag in SESSION_ATTRIBUTE object as specified in
   [RFC3209]. Nevertheless, the following combinations are valid:
   1) If both Label and Component Link flags are clear, then neither
      Labels nor Component Links are recorded.
   2) If Label Recording flag is set and Component Link flag is clear,
      then only Label Recording is performed as defined in [RFC3209].
   3) If Label Recording flag is clear and Component Link flag is set,
      then Component Link Recording is performed as defined in this
      proposal.

D.Papadimitriou (Editor)                                             9

draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt        May 2004

   4) If both Label Recording and Component Link flags are set, then
      Label Recording is performed as defined in [RFC3209] and also
      Component Link recording is performed as defined in this
      proposal.

   In most cases a node initiates recording for a given LSP by adding
   the RRO to the Path message. If the node desires Component Link
   recording and if the outgoing TE link is bundled, then the initial
   RRO contains the Component Link identifier (numbered or unnumbered)
   as selected by the sender. As well, the "Component Link Recording
   desired" flag is set in the LSP_ATTRIBUTE object. If the node also
   desires label recording, it sets the Label_Recording flag in the
   SESSION_ATTRIBUTE object.

   When a Path message with the "Component Link Recording desired" flag
   set is received by an intermediate node, if a new Path message is to
   be sent for a downstream bundled TE link, the node adds a new
   Component Link subobject to the RRO and appends the resulting RRO to
   the Path message before transmission.

   Note that, unlike Labels, Component Link identifiers are always
   known on receipt of the Path message.

   When the destination node of an RSVP session receives a Path message
   with an RRO and the "Component Link Recording desired" flag set,
   this indicates that the sender node needs TE route as well as
   component link recording.  The destination node initiates the RRO
   process by adding an RRO to Resv messages. The processing mirrors
   that of the Path messages

   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.

8. Backward Compatibility Issues

   TBD.

9. Security Considerations

   This draft introduces no new security considerations to either
   [RFC3473] or [RFC3477]. GMPLS security is described in section 11
   of [RFC3471] and refers to [RFC3209] for RSVP-TE.

10. IANA Considerations

   IF_ID TLV type values are not currently tracked or managed by IANA.
   This might be a good opportunity to move them under IANA control.

D.Papadimitriou (Editor)                                            10

draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt        May 2004


   This document defines the following:

   1. Subobjects of the EXPLICIT_ROUTE object (C-Type 1):
      - Component Interface identifier IPv4            10 (TBA)
      - Component Interface identifier IPv6            11 (TBA)
      - Component Interface identifier Unnumbered      12 (TBA)

   2. Subobjects of the RECORD_ROUTE object (C-Type 1):
      - Component Interface identifier IPv4            10 (TBA)
      - Component Interface identifier IPv6            11 (TBA)
      - Component Interface identifier Unnumbered      12 (TBA)

   3. LSP Attributes Flag Registry value (if not included in the
      SESSION_ATTRIBUT object flags)
      - Component Link Recording desired               7 (TBA)

11. Intellectual Property Consideration

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology
   described in this document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights. Information on the procedures with respect to rights
   in RFC documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention
   any copyrights, patents or patent applications, or other
   proprietary rights that may cover technology that may be required
   to implement this standard. Please address the information to the
   IETF at ietf-ipr@ietf.org.

12.1 IPR Disclosure Acknowledgement

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been
   disclosed, and any of which I become aware will be disclosed, in
   accordance with RFC 3668.

13. Acknowledgments

   This document is the work of numerous authors and consists of a
   composition of a number of previous documents in this area,
   including:


D.Papadimitriou (Editor)                                            11

draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt        May 2004

   draft-farrel-ccamp-ifid-unnum-00.txt
   draft-zamfir-explicit-resource-control-bundle-03.txt

14. References

14.1 Normative References

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels," BCP 14, RFC 2119, March 1997.

   [RFC2205]   Braden, R., et al., "Resource ReSerVation Protocol
               (RSVP) -- Version 1 Functional Specification," RFC
               2205, September 1997.

   [RFC2210]   Wroclawski, J., "The Use of RSVP with IETF Integrated
               Services," RFC 2210, September 1997.

   [RFC3209]   Awduche, D. et al., "RSVP-TE: Extensions to RSVP for
               LSP Tunnels," RFC 3209, December 2001.

   [RFC3471]   Berger, L. (Editor) et al., "Generalized Multi-
               Protocol Label Switching (GMPLS) Signaling -
               Functional Description," RFC 3471, January 2003.

   [RFC3473]   Berger, L. (Editor) et al., "Generalized Multi-
               Protocol Label Switching (GMPLS) Signaling Resource
               ReserVation Protocol-Traffic Engineering (RSVP-TE)
               Extensions," RFC 3473, January 2003.

   [RFC3477]   Kompella, K., Rekhter, Y., "Signalling Unnumbered
               Links in RSVP-TE", RFC 3477, January 2003.

   [RFC3667]   Bradner, S., "IETF Rights in Contributions", BCP 78,
               RFC 3667, February 2004.

   [RFC3668]   Bradner, S., Ed., "Intellectual Property Rights in IETF
               Technology", BCP 79, RFC 3668, February 2004.

14.2 Informative References

   [CRANKBACK] Farrel, A. (Editor), "Crankback Signaling Extensions
               for MPLS Signaling", Internet Draft (work in progress),
               draft-ietf-ccamp-crankback-01.txt, January 2004.

   [GMPLS-ARCH]Mannie, E. (Editor) et al., "Generalized Multi-Protocol
               Label Switching (GMPLS) Architecture," Internet Draft
               (work in progress), draft-ietf-ccamp-gmpls-
               architecture-07.txt, May 2003.

   [GMPLS-RTG] Kompella, K. (Editor) et al., "Routing Extensions in
               Support of Generalized MPLS," Internet Draft (work in
               progress), draft-ietf-ccamp-gmpls-routing-09.txt,
               October 2003.


D.Papadimitriou (Editor)                                            12

draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt        May 2004

   [IF-ID]    Farrel, A. et al., "Identification of Component Links
              of Unnumbered Interfaces," Internet Draft (work in
              progress), draft-farrel-ccamp-ifid-unnum-00.txt,
              February 2004.

   [ERC]      Zamfir, A. et al., "Component Link Recording and
              Resource Control for GMPLS Link Bundles," Internet
              Draft (work in progress), draft-zamfir-explicit-
              resource-control-bundle-03.txt, February 2004.

15. Authors Addresses

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

   Adrian Farrel
   Old Dog Consulting
   Phone: +44 (0) 1978 860944
   EMail: adrian@olddog.co.uk

   Dimitri Papadimitriou (Editor)
   Alcatel
   Francis Wellesplein 1,
   B-2018 Antwerpen, Belgium
   Phone: +32 3 240-8491
   Email: dimitri.papadimitriou@alcatel.be

   Arun Satyanarayana
   Movaz Networks, Inc.
   7926 Jones Branch Drive, Suite 615
   McLean, VA 22102, USA
   Phone: +1 703 847-1785
   EMail: aruns@movaz.com

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











D.Papadimitriou (Editor)                                            13

draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt        May 2004

Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."




























D.Papadimitriou (Editor)                                            14


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