[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ayyangar-ccamp-inter-domain-rsvp-te) 00 01 02 03 04 05 06 07 RFC 5151

IETF Internet Draft                             Arthi Ayyangar(Editor)
Proposed Status: Standards Track                      Juniper Networks
Expires: September 2006
                                         Jean-Philippe Vasseur(Editor)
                                                   Cisco Systems, Inc.

                                                          March 2006

      Inter domain GMPLS Traffic Engineering - RSVP-TE extensions

              draft-ietf-ccamp-inter-domain-rsvp-te-03.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on September 6, 2006.


Copyright Notice

Copyright (C) The Internet Society (2006).  All Rights Reserved.

Abstract

This document describes extensions to Generalized Multi-Protocol Label
Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering
(RSVP-TE) signaling required to support mechanisms for the establishment
and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths



Ayyangar and Vasseur                                            [Page 1]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


(LSPs), both packet and non-packet, that traverse multiple domains. For
the purpose of this document, a domain is considered to be any
collection of network elements within a common realm of address space or
path computation responsibility. Examples of such domains include
Autonomous Systems, IGP areas and GMPLS overlay networks.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Conventions used in this document  . . . . . . . . . . . .  3
     1.2   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Signaling overview   . . . . . . . . . . . . . . . . . . . . .  4
     2.1   Signaling options  . . . . . . . . . . . . . . . . . . . .  4
   3.  Procedures on the domain boundary node . . . . . . . . . . . .  5
     3.1   Rules on ERO processing  . . . . . . . . . . . . . . . . .  6
     3.2   LSP setup failure and crankback  . . . . . . . . . . . . .  8
     3.3   RRO processing across domains  . . . . . . . . . . . . . .  9
   4.  RSVP-TE signaling extensions . . . . . . . . . . . . . . . . .  9
     4.1   Control of downstream choice of signaling method . . . . .  9
   5.   Protection and recovery of inter-domain TE LSPs . . . . . . . 11
     5.1   Fast Recovery support using MPLS TE Fast Reroute . . . . . 11
       5.1.1   Failure within a domain (link or node failure) . . . . 11
       5.1.2   Failure of link at domain boundaries . . . . . . . . . 11
       5.1.3   Failure of a boundary node . . . . . . . . . . . . . . 12
     5.2   Protection and recovery of GMPLS LSPs  . . . . . . . . . . 13
   6.   Re-optimization of inter-domain TE LSPs . . . . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
     8.1   Attribute Flags for LSP_ATTRIBUTES object  . . . . . . . . 15
     8.2   New Error Codes  . . . . . . . . . . . . . . . . . . . . . 16
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
  10.  References   . . . . . . . . . . . . . . . . . . . . . . . . . 16
      10.1   Normative References . . . . . . . . . . . . . . . . . . 16
      10.2   Informative References . . . . . . . . . . . . . . . . . 17
   Appendix 1:   Examples . . . . . . . . . . . . . . . . . . . . . . 18
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
       Intellectual Property and Copyright Statements . . . . . . . . 23














Ayyangar and Vasseur                                            [Page 2]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


1. Introduction

   The requirements for inter-area and inter-AS MPLS Traffic Engineering
   have been developed by the Traffic Engineering Working Group and have
   been stated in [INTER-AREA-TE-REQS] and [INTER-AS-TE-REQS]
   respectively. Many of these requirements also apply to GMPLS
   networks. The framework for inter-domain GMPLS Traffic Engineering
   has been provided in [INTER-DOMAIN-FRAMEWORK].

   This document presents the RSVP-TE signaling extensions for the setup
   and maintenance of TE LSPs that span multiple domains. The signaling
   procedures described in this document are applicable to both MPLS
   packet LSPs ([RSVP-TE]) and all LSPs that use RSVP-TE GMPLS
   extensions as described in [RSVP-GMPLS]. Three different signaling
   methods along with the corresponding RSVP-TE extensions and
   procedures are proposed in this document.

   For the purpose of this document, a domain is considered to be any
   collection of network elements within a common realm of address space
   or path computation responsibility. Examples of such domains include
   Autonomous Systems, IGP areas and GMPLS overlay networks ([GMPLS-
   OVERLAY]).

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

1.2. Terminology

   ASBR: routers used to connect together ASes of a different or the
   same Service Provider via one or more Inter-AS links.

   Bypass Tunnel: an LSP that is used to protect a set of LSPs passing
   over a common facility.

   ERO: Explicit Route Object

   H-LSP: Hierarchical LSP

   FA-LSP: Forwarding Adjacency LSP

   LSP: MPLS Label Switched Path

   MP: Merge Point. The node where bypass tunnels meet the protected
   LSP.




Ayyangar and Vasseur                                            [Page 3]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


   NHOP bypass tunnel: Next-Hop Bypass Tunnel. A backup tunnel, which
   bypasses a single link of the protected LSP.

   NNHOP bypass tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel,
   which bypasses a single node of the protected LSP.

   PLR: Point of Local Repair. The head-end of a bypass tunnel.

   Protected LSP: an LSP is said to be protected at a given hop if it
   has one or multiple associated backup tunnels originating at that
   hop.

   RRO - Record Route Object

   TE: Traffic Engineering

   TE LSP: Traffic Engineering Label Switched Path

   TE link: Traffic Engineering link

   TED: MPLS Traffic Engineering Database


2. Signaling overview

   The RSVP-TE signaling of a TE LSP within a single domain is described
   in [RSVP-TE] and [RSVP-GMPLS]. This document focuses on the RSVP-TE
   signaling extensions required for inter-domain TE LSP setup and
   maintenance. Any other extensions that may be needed for routing or
   path computation are outside the scope of this document.

2.1. Signaling options

   There are three ways in which an RSVP-TE LSP could be signaled across
   multiple domains:

   Contiguous - A contiguous TE LSP is a single end-to-end TE LSP that
   is setup across multiple domains using RSVP-TE signaling procedures
   described in [RSVP-TE] and [RSVP-GMPLS]. No additional TE LSPs are
   required to signal a contiguous TE LSP and the same RSVP-TE
   information for the TE LSP is maintained along the entire LSP path.

   Nesting - Nesting one or more TE LSPs into another TE LSP is
   described in [LSP-HIERARCHY]. This technique can be used to nest one
   or more inter-domain TE LSPs into an intra-domain hierarchical LSP
   (H-LSP). Label stacking construct may be used to achieve nesting,
   when appropriate, say in packet networks. In the rest of this
   document, the term H-LSP is used to refer to an LSP that allows



Ayyangar and Vasseur                                            [Page 4]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


   nesting of other LSPs into it and that may or may not be advertised
   as a TE link. Furthermore, an H-LSP may or may not be an FA-LSP [LSP-
   HIERARCHY].

   Stitching - The concept of LSP stitching as well as the required
   signaling procedures is described in [LSP-STITCHING]. This technique
   can be used to stitch an inter-domain TE LSP to an intra-domain LSP
   segment. A inter-domain stitched TE LSP is a TE LSP made up of
   different TE LSP segments within each domain which are "stitched"
   together in the data plane so that an end-to-end LSP is achieved in
   the data plane. In the control plane, however, the different LSP
   segments are signaled as distinct RSVP sessions which are independent
   from the RSVP session for the inter-domain LSP. While stitching is
   similar to nesting in the control plane, in the data plane, stitching
   allows for only one inter-domain LSP to be associated with any one
   intra-domain LSP, and does not require the use of label stacks.

   On receipt of an LSP setup request for an inter-domain TE LSP, the
   decision of whether to signal the LSP contiguously or whether to nest
   or stitch it to another TE LSP, depends on the signaled TE LSP
   characteristics from the head-end node or the local node
   configuration, when not explicitly signaled. Also, the TE LSP segment
   or H-LSP within the domain may either be pre-configured or signaled
   dynamically based on the arrival of the inter-domain TE LSP setup
   request.



3. Procedures on the domain boundary node

   Whether an inter-domain TE LSP is contiguous, nested or stitched is
   determined mostly by the signaling method supported by or configured
   on the intermediate nodes, usually the domain boundary nodes that the
   inter-domain TE LSP traverses. It also depends on certain parameters
   that may be signaled by the head-end node for the inter-domain TE
   LSP.

   When a domain boundary node receives the RSVP Path message for an
   inter-domain TE LSP setup, it MUST carry out the following procedures
   before it can forward the Path message to the next node along the
   path:

     1. Apply any locally configured policies. In case of a policy
        failure, the node SHOULD fail the setup of the LSP and
        originate a PathErr with error code=2 ("Policy control
        failure") and error sub-code="Inter-domain policy failure"
        (TBD).




Ayyangar and Vasseur                                            [Page 5]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


     2. Determine the signaling method to be used. The head-end node
        of the inter-domain TE LSP may have explicitly specified a
        signaling method or if the signaling method is not explicitly
        signaled, then the node MAY determine the signaling method
        based on local configuration and policies. If the desired
        signaling method signaled by the head-end cannot be supported
        at this node for some reason, then a PathErr message as
        described in Section 4.1 MUST be generated.

     3. Carry out ERO procedures as described in the next section in
        addition to the procedures in [RSVP-TE] and [RSVP-GMPLS].

     4. Perform any path computations as required (say for ERO
        expansion). The path computation procedure itself is outside
        the scope of this document. One such path computation option is
        addressed in [INTER-DOMAIN-PD-PATH-COMP]. Another option is to
        use a Path Computation Element (PCE) ([PCE]) for path
        computation. Path computation may itself involve determining the
        exit point from the TE domain ([INTER-DOMAIN-PD-PATH-COMP]).

       4a. In case of nesting or stitching, either find an existing
           intra-domain TE LSP to carry the inter-domain TE LSP or
           signal a new one, depending on local policy.

       4b. In case of a path computation failure, a PathErr SHOULD be
           generated as described in [INTER-DOMAIN-PD-PATH-COMP].

     5. In case of any other RSVP signaling failures, procedures as
        described in [RSVP-TE] and [RSVP-GMPLS] SHOULD be followed.
        Follow procedures related to LSP setup failure and crankback
        as described in Section 3.2, where applicable.

     6. Carry out RRO procedures as described in Section 3.3, if
        applicable.


3.1. Rules on ERO processing

   The ERO that a domain boundary node receives in the Path message for
   an inter-domain TE LSP will be dependent on several factors such as
   the level of visibility that the head-end node of the inter-domain TE
   LSP has into other domains, the path computation techniques applied
   at the head-end node, policy agreements between two domains; etc.
   Eventually, when the ERO reaches a domain boundary node, the
   following rules SHOULD be used for ERO processing and signaling.
   Within a domain, there may be no H-LSPs or LSP segments. If they are
   present, then they may originate and terminate on domain boundary
   nodes. There could also be H-LSPs and LSP segments that may originate



Ayyangar and Vasseur                                            [Page 6]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


   and terminate at other nodes in the domain. In general, these ERO
   processing rules are also applicable to non-boundary nodes that may
   participate in signaling the inter-domain TE LSP.

     1. If there are any policies related to ERO processing for the
        LSP, they SHOULD be applied and corresponding actions should be
        taken. E.g. there could exist a policy to reject inter-domain
        LSP setup request containing an ERO with subobjects identifying
        nodes within the domain. In case of inter-domain LSP setup
        failures due to policy failures related to ERO processing, the
        node SHOULD issue a PathErr with error code=2 ("Policy control
        failure") and error sub-code="Inter-domain explicit route
        rejected" (TBD).

     2. Section 8.2 of [LSP-HIERARCHY] describes how a node at the
        edge of a region (domain) processes the ERO in the incoming
        Path message and uses this ERO, to either find an existing H-LSP
        or signal a new H-LSP using the ERO hops. This also includes
        adjusting the ERO before sending the Path message to the next
        hop node. These procedures SHOULD also be followed for nesting
        or stitching of inter-domain TE LSPs to H-LSPs or LSP segments
        respectively. While the domain boundaries are tied to link
        switching capabilities in [LSP-HIERARCHY], these procedures are
        also applicable to other domain boundary nodes in the context
        of this document.

     3. If the ERO subobject identifies a TE link formed by a H-LSP or
        LSP segment within the domain, either numbered or unnumbered,
        then a contiguous LSP MUST NOT be signaled. The node MUST either
        nest or stitch the inter-domain TE LSP to the local H-LSP or LSP
        segment. If, however, the head-end node for the inter-domain LSP
        has requested that the inter-domain TE LSP be contiguous, then
        this is a conflict and a PathErr with error code=24 ("Routing
        Problem") and error sub-code="ERO conflicts with inter-domain
        signaling method" (TBD) SHOULD be issued.

     4. In the absence of any ERO subobjects, the LSP destination in
        the SESSION object SHOULD be considered as the next loose hop.
        A node may also receive an ERO with explicit IPv4, IPv6 or AS
        number loose hops. In such cases, a path computation to expand
        this loose hop SHOULD be carried out. Path computation as
        described in [INTER-DOMAIN-PD-PATH-COMP] or using a PCE should
        be used to expand the ERO in these cases and to determine the
        intermediate hops.

     5. In case of any other failures in processing the ERO hop(s), a
        PathErr message with appropriate error codes as described in
        [RSVP-TE] or [RSVP-GMPLS] SHOULD be generated.



Ayyangar and Vasseur                                            [Page 7]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


3.2. LSP setup failure and crankback

   In case of any setup failures along the path due to policy or
   admission control or other reasons, a corresponding
   PathErr/ResvErr/Notify is generated and sent upstream and/or
   downstream. An ERROR_SPEC comprises of information regarding the
   point of failure (network element) and details about the failure
   itself. When an LSP traverses multiple domains, a failure could be
   generated in any domain along the path and an error notification may
   need to be propagated across multiple domains. So, an error
   notification message itself may be subjected to policies as it
   traverses domain boundaries and a boundary node MAY modify domain
   specific information carried in the error message. E.g. the error
   node address in the RSVP ERROR_SPEC or IF_ID ERROR_SPEC or the
   Interface Identifier in IF_ID ERROR_SPEC may be modified at the
   boundary node for confidentiality reasons. Nodes other than domain
   boundary nodes SHOULD NOT modify ERROR_SPEC contents. It is also
   RECOMMENDED that such a policy be implemented only on domain boundary
   nodes for inter-domain LSPs where preserving confidentiality is a
   requirement.

   Also, in case of an inter-domain LSP setup failure, there may be
   cases when the error is not propagated all the way upstream to the
   head-end node. A PathErr may be intercepted by a boundary node in the
   domain in which the error is generated (or any other node along the
   path) and this node may attempt to find an alternate path.  Finding
   an alternate path means finding a new path downstream to the node
   performing re-routing and avoiding the failed network elements.  This
   may involve finding a path within the domain experiencing the failure
   or it may mean finding new boundary node(s) or new downstream domain.

   Crankback re-routing depends not only on local configuration and
   ability of a boundary node to do local crankback re-routing, but also
   on any specific parameters requested by the head-end node itself for
   that LSP. In certain cases, it may be desirable for the head-end node
   to exert some control on whether crankback re-routing at intermediate
   nodes is desirable or not. Procedures and extensions described in
   [CRANKBACK] should be followed for crankback re-routing.  When
   crankback re-routing is allowed, a node along the TE LSP path may
   either decide to forward the PathErr message upstream towards the
   head-end node of the inter-domain TE LSP or try to determine an
   alternate path around the failure. When crankback re-routing is not
   allowed or if the node cannot perform crankback re-routing, then, on
   receiving a PathErr message, the node should propagate the PathErr
   message upstream.

   [RSVP-GMPLS] allows nodes to generate a targeted Notify message in
   addition to a PathErr/ResvErr message, to expedite error



Ayyangar and Vasseur                                            [Page 8]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


   notification, if a Notify Request has been received in the
   corresponding Path/Resv message. This is also applicable to inter-
   domain TE LSPs which implement [RSVP-GMPLS]. However, since PathErr
   and Notify need not follow the same path, their recepient nodes could
   be different. This has certain implications on crankback re-routing.
   Procedures and recommendations in [CRANKBACK] should be followed for
   Notify message processing for crankback re-routing.

3.3. RRO processing across domains

   [RSVP-TE] defines the RECORD_ROUTE object (RRO) as an optional
   object, which is primarily used for loop detection and for providing
   information about the hops traversed by LSPs. [FAST-REROUTE] also
   uses the RRO to record labels and determine MP. The address or ID
   recorded in the RRO usually represents a link/interface. This
   information by itself may not be useful enough when LSPs traverse
   domains. [NODE-ID] defines extensions which allows a node to record
   its node ID in the RRO, to provide an additional context for the link
   address/ID.

   Note that there may also be cases while traversing administrative
   domain boundaries, where a network may not wish to expose its
   internal addresses/IDs to preserve confidentiality. In such cases RRO
   MAY be subjected to policies, filtering and modifications at domain
   boundaries. Internal network element identities may be masked off and
   replaced with boundary information or AS information, by domain
   boundary entities. This is not expected to hamper the working of the
   signaling protocol. This does, however, result in information loss,
   thereby leading to inefficient paths or procedures that depend on RRO
   information.


4. RSVP-TE signaling extensions

   The following RSVP-TE signaling extensions are introduced in this
   document.

4.1. Control of downstream choice of signaling method

   In certain mixed environments with different techniques (contiguous,
   stitched or nested TE LSPs), a head-end node of the inter-domain TE
   LSP may wish to signal its requirement regarding the signaling method
   used at an intermediate node along the path.

   [LSP-ATTRIBUTES] defines the format of the Attributes Flags TLV
   included in the LSP_ATTRIBUTES object carried in an RSVP Path
   message. The following bit in the Flags TLV is used by the head-end
   node of the inter-domain TE LSP to restrict the signaling method used



Ayyangar and Vasseur                                            [Page 9]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


   by the intermediate nodes to be contiguous.

   Bit Number 4 (TBD): Contiguous LSP bit - this flag is set by the
   head-end node that originates the inter-domain TE LSP if it desires a
   contiguous end-to-end TE LSP (in the control & data plane). When set,
   this indicates that an intermediate node MUST NOT perform any
   stitching or nesting on the TE LSP and the TE LSP MUST be routed as
   any other TE LSP (it must be contiguous end to end). When this bit is
   cleared, an intermediate node MAY decide to perform stitching or
   nesting. This bit MUST NOT be modified by any downstream node.

   An intermdediate node that supports the LSP_ATTRIBUTES object and the
   Attributes Flags TLV, and also recognizes the "Contiguous LSP" bit,
   but cannot support contiguous TE LSP MUST send a Path Error message
   upstream with an error code=24 ("Routing Problem") and error sub-
   code="Contiguous LSP type not supported" (TBD).

   If an intermediate node receiving a Path message with the "Contiguous
   LSP" bit set in the Flags field of the LSP_ATTRIBUTES, recognizes the
   object, the TLV and the bit and also supports the desired contiguous
   LSP behavior, then it MUST signal a contiguous LSP and MUST set the
   "Contiguous LSP signaled" bit in the Flags field of the RRO
   Attributes subobject in the corresponding Resv message.

   However, if the intermediate node supports the LSP_ATTRIBUTES object
   but does not recognize the Attributes Flags TLV, or supports the TLV
   as well, but does not recognize this particular bit, then it SHOULD
   simply ignore the above request. It MAY signal any type of LSP in
   this case. The "Contiguous LSP signaled" bit in the Flags field of
   the RRO Attributes SHOULD NOT be set.

   An ingress node for an inter-domain LSP requesting a contiguous LSP
   SHOULD examine the RRO Attributes subobject Flags to determine if the
   LSP was indeed signaled contiguous end to end. If the "Contiguous LSP
   signaled" bit is cleared, the head end may take appropriate actions
   such as restricting the type of traffic that gets mapped to this LSP,
   tearing down the LSP, or rerouting the LSP around the nodes that do
   not support the contiguous signaling; etc. Choice of action to be
   taken is upto the implementation on the ingress node and it is out of
   the scope of this document to recommend any particular action.











Ayyangar and Vasseur                                           [Page 10]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


5. Protection and recovery of inter-domain TE LSPs

   The procedures described in Section 3 MUST be applied to all inter-
   domain TE LSPs, including bypass tunnels, detour LSPs [FAST-REROUTE]
   or segment recovery LSPs [SEGMENT-PROTECTION] that may cross domains.
   This means that these LSPs will also be subjected to ERO processing,
   policies, path computation; etc. Also, note that the explicit route
   for these backup LSPs needs to be either configured or computed at
   the PLR. Just like any inter-domain TE LSP, depending on the
   visibility into the subsequent domain, the ERO may comprise of strict
   and/or loose hops. So, if there are loose hops, backup LSPs would
   also need to undergo loose hop expansion at nodes other than the PLR.
   So, the PLR in this case needs to signal the node or link that needs
   to be excluded for backup computation to other downstream nodes along
   the backup path. It is also possible that some protection schemes
   already signal this information in the DETOUR object([FAST-REROUTE]).
   However, the mechanisms for signaling this are out of scope of this
   document. [EXCLUDE-ROUTE] discusses one such solution to achieve
   this.

5.1. Fast Recovery support using MPLS TE Fast Reroute (FRR)

   [FAST-REROUTE] describes two methods for local protection for a
   packet TE LSP in case of link, SRLG or node failure. This section
   describes how these mechanisms work with the proposed signaling
   solutions for inter-domain TE LSP setup.

5.1.1. Failure within a domain (link or node failure)

   The mode of operation of MPLS TE Fast Reroute to protect a
   contiguous, stitched or nested TE LSP within a domain is identical to
   the existing procedures described in [FAST-REROUTE]. In case of
   nested or stitched inter-domain TE LSPs, protecting the intra-domain
   TE H-LSP or LSP segment will automatically protect the traffic on the
   inter-domain TE LSP. No new extensions are required for any of the
   signaling methods.

5.1.2. Failure of link at domain boundaries

   The procedures for doing link protection of the link at domain
   boundaries is the same for contiguous, nested and stitched TE LSPs.

   To protect an inter-domain link with MPLS TE Fast Reroute, a set of
   backup tunnels must be configured or dynamically computed between the
   two domain boundary nodes diversely routed from the protected inter-
   domain link. The region connecting two domains may not be TE enabled.
   In this case, an implementation will have to support the set up of TE
   LSP over a non-TE enabled region.



Ayyangar and Vasseur                                           [Page 11]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


   For each protected inter-domain TE LSP traversing the protected link,
   a NHOP backup must be selected by a PLR (i.e domain exit boundary
   router), when the TE LSP is first set up. This requires for the PLR
   to select a bypass tunnel terminating at the NHOP.  Finding the NHOP
   bypass tunnel of an inter-AS LSP can be achieved by analyzing the
   content of the RRO object received in the RSVP Resv message of both
   the bypass tunnel and the protected TE LSP(s). As defined in [RSVP-
   TE], the addresses specified in the RRO IPv4 subobjects can be node-
   ids and/or interface addresses (with specific recommendation to use
   the interface address of the outgoing Path messages). The PLR may or
   may not have sufficient topology information to find where the backup
   tunnel intersects the protected TE LSP based on the RRO. [NODE-ID]
   proposes a solution to this issue, defining an additional RRO IPv4
   suboject that specifies a node-id address.

5.1.3. Failure of a boundary node

   For each protected inter-domain TE LSP traversing the boundary node
   to be protected, a NNHOP backup must be selected by the PLR. This
   requires the PLR to setup a bypass tunnel terminating at the NNHOP.
   Finding the NNHOP bypass tunnel of an inter-domain TE LSP can be
   achieved by analyzing the content of the RRO object received in the
   RSVP Resv message of both the bypass tunnel and the protected TE
   LSP(s) (see [NODE-ID]). The main difference with node protection,
   between a protected contiguous inter-domain TE LSP and a protected
   nested or stitched inter-domain TE LSP is that the PLR and NNHOP (MP)
   in case of a contiguous TE-LSP could be any node within the domain.
   However, in case of a nested or stitched TE-LSP the PLR and MP can
   only be the end-points of the H-LSP or LSP segment. The consequence
   is that the backup path is likely to be longer and if bandwidth
   protection is desired, for instance, ([FAST-REROUTE]) more resources
   may be reserved in the domain than necessary.  Note, however, that
   even for a contiguous LSP, there may be cases where the addresses
   within the domain could have been masked in the RRO for
   confidentiality reasons, in which case, the RRO for the contiguous
   LSP may only contain boundary nodes, and so the MP can only be a
   boundary node.

   Also, while a contiguous LSP does allow backup LSPs to terminate
   inside the domain, there could be policies which may reject an LSP
   that originates in another domain from carrying addresses in ERO that
   are local to this domain. In these cases, the backup LSP cannot
   terminate inside the domain and must terminate only at the boundary
   node.

   In case of stitching or nesting, when the node to be protected is the
   H-LSP/S-LSP tail-end node, the PLR is not immediately upstream of
   this node. Hence, the failure detection time on failure of H-LSP/S-



Ayyangar and Vasseur                                           [Page 12]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


   LSP tail-end node is bound to be longer than that in the case where
   PLR is immediately upstream of the node to be protected.  In such
   cases, it is RECOMMENDED that the PLR rely on methods proposed in
   [BFD-MPLS] to rapidly detect H-LSP/S-LSP tail-end node failure. This
   would help in fast recovery.

5.2. Protection and recovery of GMPLS LSPs

   [SEGMENT-PROTECTION] describes GMPLS based segment recovery. This
   allows protection against a span failure, a node failure, or failure
   over any particular portion of a network used by an LSP. The
   scenarios described above for MPLS Fast reroute also apply to segment
   protection. No new extensions are needed for segment protection of
   LSPs that span multiple domains. However, in the inter-domain LSP
   case, it may not always be possible for the upstream node (outside a
   domain) to identify end-points of segment recovery LSP in another
   domain. Even if this was somehow determined, SERO and SRRO in the
   recovery LSP MUST be subjected to ERO and RRO processing rules as
   described above, so policy could disallow explicit control of LSP
   segment recovery inside the domain by a node outside the domain.
   This is treated as a Segment Protection failure and error handling as
   described in Section 4.2.1 of [SEGMENT-PROTECTION].


6. Re-optimization of inter-domain TE LSPs

   Re-optimization of a TE LSP is the process of moving the LSP from the
   current path to a more prefered path. This usually involves
   computation of the new prefered path and make-before-break signaling
   procedures [RSVP-TE], to minimize traffic disruption.  The path
   computation procedures involved in re-optimization of an inter-domain
   TE LSP are covered in [INTER-DOMAIN-PD-PATH-COMP].  Another option is
   to use PCE-based mechanisms ([PCE]) for re-optimization.

   In the context of an inter-domain TE LSP, since the LSP traverses
   multiple domains, re-optimization may be required in one or more
   domains at a time. Again, depending on the nature of the LSP and/or
   policies and configuration at domain boundaries (or other nodes), one
   may either always want the head-end node of the inter-domain TE LSP
   to be notified of any local need for re-optimizations and let the
   head-end initiate the make-before-break process or one may want to
   restrict local re-optimizations with the domain.

   [LOOSE-REOPT] describes mechanisms that allow,

     o The head-end node to trigger on every node whose next hop is
       a loose hop the re-evaluation of the current path in order to
       detect a potentially more optimal path. This is done via



Ayyangar and Vasseur                                           [Page 13]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


       explicit signaling request: the head-end node sets the
       "ERO Expansion request" bit of the SESSION-ATTRIBUTE object
       carried in the RSVP Path message.

     o A node whose next hop is a loose-hop to signal to the head-end
       node that a better path exists. This is performed by sending an
       RSVP PathErr Notify message (error-code = 25), sub-code=6 (Better
       path exists). This indication may either be sent in response to
       a query sent by the head-end node or spontaneously by any node
       having detected a more optimal path.

   The above mechanisms SHOULD be used for a contiguous inter-domain TE
   LSP to allow the head-end node of the inter-domain TE LSP to initiate
   make-before-break procedures. For nested or stitched TE LSPs, it is
   possible to re-optimize the local H-LSP or LSP segment without
   involving the head-end node of the inter-domain TE LSP.  This will
   automatically re-route the traffic for the inter-domain TE LSP along
   the new path, within the domain. Such local re-optimizations,
   including parameters for re-optimization can be controlled by local
   policy or configuration in that domain.


7. Security Considerations

   When signaling an inter-domain RSVP-TE LSP, an operator may make use
   of the already defined security features related to RSVP-TE
   (authentication). This may require some coordination between the
   domains to share the keys (see RFC 2747 and RFC 3097). Note that this
   may involve additional synchronization, should the domain boundary
   LSR be protected with MPLS TE Fast Reroute, since the merge point
   should also share the key.

   For an inter-domain TE LSP, especially when it traverses different
   administrative or trust domains, the following mechanisms (also see
   [INTER-AS-TE-REQS]) SHOULD be provided to an operator :-

     1) a way to enforce policies and filters at the domain boundaries
        to process the incoming inter-domain TE LSP setup requests
        (Path messages) based on certain agreed trust and service
        levels/contracts between domains. Various LSP attributes
        such as bandwidth, priority; etc could be part of such a
        contract.

     2) a way for the operator to rate limit LSP setup requests
        or error notifications from a particular domain.

     3) a mechanism to allow policy-based outbound RSVP message
        processing at the domain boundary LSR, which may involve



Ayyangar and Vasseur                                           [Page 14]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


        filtering or modification of certain addresses in RSVP
        objects and messages.

   Some examples of the policies described above are:-

     1) An operator may choose to implement some kind of ERO filtering
        policy on the domain boundary LSR to disallow or ignore hops
        within the domain being identified in the ERO of an incoming
        Path message.

     2) In order to preserve confidentiality, an operator may choose
        to disallow recording of hops within the domain in the RRO or
        may choose to filter out certain recorded RRO addresses at the
        domain boundary LSR.

     3) An operator may require the boundary LSR to modify the addresses
        of certain messages like PathErr or Notify originated from hops
        within the domain.

   Note that the detailed specification of such mechanisms (local
   implementation) is outside the scope of this document.


8. IANA Considerations

   The following values have to be defined by IANA for this document.
   The registry is, http://www.iana.org/assignments/rsvp-parameters.

8.1. Attribute Flags for LSP_ATTRIBUTES object

   The following new flag bit is being defined for the Attributes Flags
   TLV in the LSP_ATTRIBUTES object. The numeric value should be
   assigned by IANA.

   Contiguous LSP bit - Bit Number 4 (Suggested value)

   This flag bit is only to be used in the Attributes Flags TLV on a
   Path message.

   The "Contiguous LSP" bit has a corresponding "Contiguous LSP
   signaled" bit (Bit Number 4) to be used in the RRO Attributes sub-
   object.









Ayyangar and Vasseur                                           [Page 15]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


8.2. New Error Codes

   The following new error sub-codes are being defined under the RSVP
   error-code "Routing Problem" (24). The numeric error sub-code value
   should be assigned by IANA. Suggested values are,

     1. Contiguous LSP type not supported - sub-code 21

     2. ERO conflicts with inter-domain signaling method - sub-code 22

   These error codes are to be used only in a RSVP PathErr.

   The following new error sub-codes are being defined under the RSVP
   error-code "Policy control failure" (2). The numeric error sub-code
   value should be assigned by IANA. Suggested values are,

     1. Inter-domain policy failure - sub-code 102

     2. Inter-domain explicit route rejected - sub-code 103


9. Acknowledgements

   The authors would like to acknowledge the input and helpful comments
   from Adrian Farrel on various aspects discussed in the document.


10. References

10.1. Normative References

   [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
   Extensions to OSPF", RFC 3630 (Updates RFC 2370), September 2003.

   [ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic
   Engineering", RFC 3784

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

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

   [LSP-HIERARCHY] Kompella K., Rekhter Y., "LSP Hierarchy with
   Generalized MPLS TE", RFC 4206, October 2005.

   [LSP-STITCHING] Ayyangar A., Vasseur JP., "LSP Stitching with



Ayyangar and Vasseur                                           [Page 16]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


   Generalized MPLS TE", (work in progress).

   [CRANKBACK] Farrel A. et al, "Crankback Signaling Extensions for MPLS
   Signaling", (work in progress).

   [LSP-ATTRIBUTES] Farrel A. et al, "Encoding of Attributes for
   Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)
   Establishment Using RSVP-TE", RFC 4420, February 2006.


10.2. Informative References

   [INTER-AS-TE-REQS] Zhang et al, "MPLS Inter-AS Traffic Engineering
   requirements", RFC 4216, November 2005.

   [INTER-AREA-TE-REQS] LeRoux JL, Vasseur JP, Boyle J. et al,
   "Requirements for support of Inter-Area MPLS Traffic Engineering",
   RFC 4105, June 2005.

   [INTER-DOMAIN-FRAMEWORK] Farrel A. et al, "A Framework for Inter-
   Domain MPLS Traffic Engineering", (work in progress).

   [INTER-DOMAIN-PD-PATH-COMP] Vasseur JP., Ayyangar A., Zhang R., "A
   Per-domain path computation method for computing Inter-domain Traffic
   Engineering Label Switched Path", (work in progress).

   [PCE] Ash, G., Farrel, A., and Vasseur, JP., "Path Computation
   Element (PCE) Architecture", draft-ietf-pce-architecture, work in
   progress.

   [GMPLS-OVERLAY] G. Swallow et al, "GMPLS UNI: RSVP-TE Support for the
   Overlay Model", RFC 4208, October 2005.

   [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE
   for LSP Tunnels",  RFC 4090, May 2005.

   [NODE-ID] Vasseur, Ali and Sivabalan, "Definition of an RRO node-id
   subobject", (work in progress).

   [SEGMENT-PROTECTION] L. Berger et al, "GMPLS Based Segment Recovery",
   (work in progress).

   [BFD-MPLS] R. Aggarwal et al, "BFD For MPLS LSPs", (work in
   progress).

   [LOOSE-REOPT] Vasseur JP. et al, "Reoptimization of an explicit
   loosely routed MPLS TE paths", (work in progress).




Ayyangar and Vasseur                                           [Page 17]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


Appendix 1: Examples

   This Appendix provides some examples to illustrate the inter-domain
   signaling procedures described in this document. We consider one
   example topology which covers inter-domain TE LSP signaling across
   Autonomous systems. Inter-domain TE LSP signaling across other
   domains covered by this document are also meant to follow similar
   signaling procedures, but are not covered here.


        <-- AS-1 --->      <--- AS-2 --->        <-- AS-3 -->

                  <---BGP--->            <---BGP-->
   CE1---R0----X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6
         | |   |   |       /  |  / |   / |          |      |
         | |   +-ASBR2----/ ASBR5  |  /  |          |      |
         | |       |          |    | /   |          |      |
       R1--R2----ASBR3------ASBR6--R4---ASBR8----ASBR10----R7---CE2

         <================ Inter-AS TE LSP ================>

   1.1 Assumptions

   - Three interconnected ASes, respectively AS-1, AS-2, and AS-3.
     Note that AS3 might be AS1 in some scenarios described in
     [INTER-AS-TE-REQS].

   - The various ASBRs are BGP peers, without any IGP running on the
     single hop link interconnecting the ASBRs

   - Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE
     extensions (see [OSPF-TE] and [ISIS-TE]). In other words, the ASes
     are TE enabled. Note that each AS can run a different IGP.

   - Each AS can be made of several areas. In this case, the TE LSP will
     rely on the inter-area TE techniques to compute and set up a TE LSP
     traversing multiple IGP areas. For the sake of simplicity, each
     routing domain will be considered as single area in this document,
     but the solutions described in this document does not prevent the
     use of multi-area techniques. In fact, these inter-domain solutions
     are equally applicable to inter-area TE.

   - An inter-AS TE LSP T1 originated at R0 in AS1 and terminating
     at R7 in AS3 with following possible explicit paths:

   o p1 - path defined by ERO with a set of loose node hops crossing
     AS-2, ASBR1(loose)-ASBR4(loose)-ASBR7(loose)-ASBR9(loose)-R7(loose)




Ayyangar and Vasseur                                           [Page 18]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


   o p2 - path defined by ERO containing a set of strict interface hops
     crossing AS-2,
     ASBR1(loose)-link[ASBR1-ASBR4](strict)-link[ASBR4-R3](strict)
     -link[R3-ASBR7](strict)-link[ASBR7-ASBR9](strict)-R7(loose)

   o p3 - path defined by ERO containing a set of AS number hops
     crossing AS-2,
     ASBR1(loose)-link[ASBR1-ASBR4](strict)-AS3(loose)-R7(loose)

   - The explicit paths (EROs) may have been configured and/or computed
     at the head-end node using any of the path computation schemes.

   1.2 ERO processing

   Let us consider an inter-AS TE LSP setup from R0 to R7, with example
   paths p1, p2. In this example, we will examine the behavior on node
   ASBR4 which is the boundary node for AS-2, for the different
   signaling methods.

   Contiguous:-

   The head-end node, R0, that desires to setup an end-to-end contiguous
   TE LSP, MAY originate a Path message with LSP_ATTRIBUTES object with
   the "Contiguous LSP" bit set in the Attributes Flags TLV.

   For path p1, additional computation to expand the loose hops may be
   required at various hops along the LSP path. When the Path message
   arrives at ASBR4, it may carry out a path computation or use some
   other means to find the intermediate hops to reach ASBR7. It may then
   adjust the outgoing ERO and forward the Path message through the
   intermediate hops in AS-2 to ASBR7.

   For path p2, the ERO next hop points to a node within the domain.
   ASBR4 will then directly forward the Path message to the next hop in
   the ERO.

   For path p3, the ERO nexthop is a loose hop pointing to the
   subsequent AS number. In this case, ASBR4 will perform path
   computation to determine the intermediate hops to reach AS-3. It may
   adjust the ERO based on the computation results. In this case either
   ASBR7 or ASBR8 may be chosen as the exit points from AS-2.
   Similarly, either ASBR9 or ASBR10 may be chosen as entry points into
   AS-3.

   Nesting and Stitching:-

   When the Path message for the inter-AS TE LSP from R0 to R7, reaches
   ASBR4, ASBR4 SHOULD first determine from the ERO hops, the boundary



Ayyangar and Vasseur                                           [Page 19]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


   node to the domain along the path. In this example, the domain
   boundary node for all paths is ASBR7. It SHOULD then use the ERO hops
   up to ASBR7 to find an existing H-LSP in case of nesting or LSP
   segment in case of stitching, that satisfies the TE constraints. If
   there are no existing H-LSPs or LSP segments and ASBR4 is capable of
   setting up the H-LSP or LSP segment on demand, it SHOULD do so using
   the ERO hops in the Path message of the inter-domain TE LSP. In
   either case, ASBR4 will adjust the ERO in the inter-domain TE LSP and
   will forward the Path message directly to the end-point of the H-LSP
   or LSP segment using the procedures described in [LSP-HIERARCHY].

   In case of path p1, since there are no ERO hops between ASBR4 and
   ASBR7, and ASBR7 hop is loose, ASBR4 may select any existing H-LSP
   (nesting) or LSP segment (stitching) that satisfies the constraints
   or it may compute a path for the H-LSP or LSP segment up to ASBR7 or
   some other intermediate node in AS-2.

   In case of path p2, ASBR4 may either select an existing H-LSP or LSP
   segment with ERO hops link[ASBR4-R3](strict)-link[R3-ASBR7](strict)
   or it may compute a new path for the H-LSP or LSP segment using the
   above hops. In either case, the ERO hops for the H-LSP or LSP segment
   MUST be the same as the signaled strict hops in that domain.

   Processing of path p3 is similar to p1 except that exit points from
   AS-2 and entry points into AS-3 are determined as part of path
   computation.

   Now, suppose, we have a path p4, defined by an ERO comprising a set
   of strict node hops crossing AS-2 as shown below,

   ASBR1(loose)-ASBR4(loose)-ASBR7(strict)-ASBR9(loose)-R7(loose)

   In this case, the ERO nexthop at ASBR4 is ASBR7(strict). In this
   case, ASBR4 will try to find or compute a H-LSP or LSP segment
   directly to ASBR7.

   The main difference between processing of p1 and p4 for nesting or
   stitching is that in case of p1, since the ERO nexthop is a loose
   hop, ASBR4 need not find a H-LSP or LSP segment directly from ASBR4
   to ASBR7. So, there could be multiple H-LSPs or LSP segments between
   ASBR4 and ASBR7 terminating and originating on other nodes. On the
   other hand, for path p4, since the ERO hop to ASBR7 is a strict hop,
   ASBR4 MUST find or signal a H-LSP or LSP segment that directly
   connects ASBR4 and ASBR7.

   1.3 Examples of local protection with MPLS FRR -

   Let us again consider the example topology above and assume that the



Ayyangar and Vasseur                                           [Page 20]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


   TE LSP is now protected. Let us consider the following backup tunnels
   in the above example,

     o B1 from ASBR1 to ASBR4 following the path
       link[ASBR1-ASBR2](strict)-link[ASBR2-ASBR4](strict) and
       protecting against a failure of the ASBR1-ASBR4 link

     o B2 from ASBR1 to R3 following the path defined by ERO,
       link[ASBR1-ASBR2](strict)-link[ASBR2-ASBR3](strict)-
       link[ASBR3-ASBR6](strict)-link[ASBR6-ASBR5](strict)-R3(strict)
       and protecting against a failure of the ASBR4 node.

     o B3 from ASBR1 to ASBR7 following the path defined by ERO,
       link[ASBR1-ASBR2](strict)-link[ASBR2-ASBR3](strict)-
       link[ASBR3-ASBR6](strict)-ASBR7(loose) and protecting against
       a failure of the ASBR4 node. In this case B3 will need additional
       path computation (loose hop expansion) on ASBR6.

     o B4 from R3 to ASBR9 following the path defined by ERO,
       link[R3-R4](strict)-link[R4-ASBR8](strict)-ASBR9(loose) and
       protecting against a failure of the ASBR7 node. B4 may involve
       loose hop expansion on ASBR8.

     o B5 from ASBR4 to ASBR9 following the path defined by ERO,
       ASBR4-ASBR8(loose)-ASBR9(loose) and protecting against a
       failure of the ASBR7 node. B5 may involve loose hop expansion
       on ASBR8.

   Note that in addition to the ERO for backup tunnels, additional
   information regarding node/link to exclude may need to be signaled as
   well if backup tunnel setup involves path computation at nodes other
   than PLR (say for loose hop expansion).

   The protected inter-domain TE LSP is an inter-AS TE LSP from R0 to R7
   with path p1. Also, for nesting or stitching, let us assume that the
   end-points of the H-LSP or LSP segment in AS-2 are ASBR4 and ASBR7.
   This gives rise to the following two scenarios for node protection:

   Protecting the boundary node at the entry to a domain :-

   Example: protecting against the failure of ASBR4

   If the inter-AS TE LSP in this example, is a contiguous LSP, then the
   PLR is ASBR1 and the NNHOP (MP) could be R3 or any other intermediate
   node along the LSP path, if this information can be gleaned from the
   RRO. A backup tunnel B2 may be used to protect the inter-AS TE LSP
   against failure of ASBR4. However, as explained in Section 5.1.3 if
   RRO information related to R3 has been masked off or if there are



Ayyangar and Vasseur                                           [Page 21]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


   restrictions on terminating the backup tunnel inside AS-2, then B2
   cannot be used. In this case B3 may be used to protect the LSP
   against failure of ASBR4.

   If the inter-AS TE LSP in this example, is nested or stitched at
   ASBR4 into an intra-domain TE H-LSP or LSP segment between ASBR4 and
   ASBR7, then the PLR is ASBR1 and the NNHOP (MP) is ASBR7. A backup
   tunnel B3 may be used to protect the inter-AS TE LSP against failure
   of ASBR4.

   Protecting the boundary node at the exit of a domain :-

   Example: protecting against failure of ASBR7.

   If the inter-AS TE LSP in this example, is a contiguous LSP, then the
   PLR could be R3 and the NNHOP (MP) is ASBR9. A backup tunnel B4 may
   be used to protect the inter-AS TE LSP against failure of ASBR7.

   If the inter-AS TE LSP in this example, is nested or stitched at
   ASBR4 into an intra-domain TE H-LSP or LSP segment between ASBR4 and
   ASBR7, then the PLR is ASBR4 and the NNHOP (MP) is ASBR9. A backup
   tunnel B5 may be used to protect the inter-AS TE LSP against failure
   of ASBR7.


Author's addresses


Arthi Ayyangar
Juniper Networks, Inc.
1194 N.Mathilda Ave
Sunnyvale, CA 94089
USA
e-mail: arthi@juniper.net

Jean Philippe Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough , MA - 01719
USA
e-mail: jpv@cisco.com










Ayyangar and Vasseur                                           [Page 22]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


Intellectual Property Statement

   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.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.












Ayyangar and Vasseur                                           [Page 23]


draft-ietf-ccamp-inter-domain-rsvp-te-03.txt                  March 2006


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.















































Ayyangar and Vasseur                                           [Page 24]


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