GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4874

Network Working Group CY. Lee Request for Comments: 4874 A. Farrel Updates: 3209, 3473 Old Dog Consulting Category: Standards Track S. De Cnodder

                                                        Alcatel-Lucent
                                                            April 2007
                   Exclude Routes - Extension to
    Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The IETF Trust (2007).

Abstract

 This document specifies ways to communicate route exclusions during
 path setup using Resource ReserVation Protocol-Traffic Engineering
 (RSVP-TE).
 The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP
 Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized
 Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation
 Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow
 abstract nodes and resources to be explicitly included in a path
 setup, but not to be explicitly excluded.
 In some networks where precise explicit paths are not computed at the
 head end, it may be useful to specify and signal abstract nodes and
 resources that are to be explicitly excluded from routes.  These
 exclusions may apply to the whole path, or to parts of a path between
 two abstract nodes specified in an explicit path.  How Shared Risk
 Link Groups (SRLGs) can be excluded is also specified in this
 document.

Lee, et al. Standards Track [Page 1] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

Table of Contents

 1. Introduction ....................................................3
    1.1. Requirements Notation ......................................4
    1.2. Scope of Exclude Routes ....................................4
    1.3. Relationship to MPLS TE MIB ................................5
 2. Shared Risk Link Groups .........................................6
    2.1. SRLG Subobject .............................................6
 3. Exclude Route List ..............................................7
    3.1. EXCLUDE_ROUTE Object (XRO) .................................7
         3.1.1. IPv4 Prefix Subobject ...............................8
         3.1.2. IPv6 Prefix Subobject ...............................9
         3.1.3. Unnumbered Interface ID Subobject ..................10
         3.1.4. Autonomous System Number Subobject .................10
         3.1.5. SRLG Subobject .....................................11
    3.2. Processing Rules for the EXCLUDE_ROUTE Object (XRO) .......11
 4. Explicit Exclusion Route .......................................13
    4.1. Explicit Exclusion Route Subobject (EXRS) .................13
    4.2. Processing Rules for the Explicit Exclusion Route
         Subobject (EXRS) ..........................................15
 5. Processing of XRO together with EXRS ...........................16
 6. Minimum Compliance .............................................16
 7. Security Considerations ........................................16
 8. IANA Considerations ............................................17
    8.1. New ERO Subobject Type ....................................17
    8.2. New RSVP-TE Class Numbers .................................18
    8.3. New Error Codes ...........................................18
 9. Acknowledgments ................................................19
 10. References ....................................................19
    10.1. Normative References .....................................19
    10.2. Informative References ...................................19
 Appendix A. Applications ..........................................21
    A.1. Inter-Area LSP Protection .................................21
    A.2. Inter-AS LSP Protection ...................................22
    A.3. Protection in the GMPLS Overlay Model .....................24
    A.4. LSP Protection inside a Single Area .......................25

Lee, et al. Standards Track [Page 2] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

1. Introduction

 The RSVP-TE specification [RFC3209] and GMPLS extensions [RFC3473]
 allow abstract nodes and resources to be explicitly included in a
 path setup, using the Explicit Route Object (ERO).
 In some systems, it may be useful to specify and signal abstract
 nodes and resources that are to be explicitly excluded from routes.
 This may be because loose hops or abstract nodes need to be prevented
 from selecting a route through a specific resource.  This is a
 special case of distributed path calculation in the network.
 For example, route exclusion could be used in the case where two
 non-overlapping Label Switched Paths (LSPs) are required.  In this
 case, one option might be to set up one path and collect its route
 using route recording, and then to exclude the routers on that first
 path from the setup for the second path.  Another option might be to
 set up two parallel backbones, dual home the provider edge (PE)
 routers to both backbones, and then exclude the local router on
 backbone A the first time that you set up an LSP (to a particular
 distant PE), and exclude the local router on backbone B the second
 time that you set up an LSP.
 Two types of exclusions are required:
 1. Exclusion of certain abstract nodes or resources on the whole
    path.  This set of abstract nodes is referred to as the Exclude
    Route list.
 2. Exclusion of certain abstract nodes or resources between a
    specific pair of abstract nodes present in an ERO.  Such specific
    exclusions are referred to as Explicit Exclusion Route.
 To convey these constructs within the signaling protocol, a new RSVP
 object and a new ERO subobject are introduced respectively.
  1. A new RSVP-TE object is introduced to convey the Exclude Route

list. This object is the EXCLUDE_ROUTE object (XRO).

  1. The second type of exclusion is achieved through a modification to

the existing ERO. A new ERO subobject type the Explicit Exclusion

   Route Subobject (EXRS) is introduced to indicate an exclusion
   between a pair of included abstract nodes.
 The knowledge of SRLGs, as defined in [RFC4216], may be used to
 compute diverse paths that can be used for protection.  In systems
 where it is useful to signal exclusions, it may be useful to signal
 SRLGs to indicate groups of resources that should be excluded on the

Lee, et al. Standards Track [Page 3] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

 whole path or between two abstract nodes specified in an explicit
 path.
 This document introduces a subobject to indicate an SRLG to be
 signaled in either of the two exclusion methods described above.
 This document does not assume or preclude any other usage for this
 subobject.  This subobject might also be appropriate for use within
 an Explicit Route object (ERO) or Record Route object (RRO), but this
 is outside the scope of this document.

1.1. Requirements Notation

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

1.2. Scope of Exclude Routes

 This document does not preclude a route exclusion from listing
 arbitrary nodes or network elements to avoid.  The intent is,
 however, to indicate only the minimal number of subobjects to be
 explicitly avoided.  For instance, it may be necessary to signal only
 the SRLGs (or Shared Risk Link Groups) to avoid.  That is, the route
 exclusion is not intended to define the actual route by listing all
 of the choices to exclude at each hop, but rather to constrain the
 normal route selection process where loose hops or abstract nodes are
 to be expanded by listing certain elements to be avoided.
 It is envisaged that most of the conventional inclusion subobjects
 are specified in the signaled ERO only for the area where they are
 pertinent.  The number of subobjects to be avoided, specified in the
 signaled XRO, may be constant throughout the whole path setup, or the
 subobjects to be avoided may be removed from the XRO as they become
 irrelevant in the subsequent hops of the path setup.
 For example, consider an LSP that traverses multiple computation
 domains.  A computation domain may be an area in the administrative
 or IGP sense, or may be an arbitrary division of the network for
 active management and path computational purposes.  Let the primary
 path be (Ingress, A1, A2, AB1, B1, B2, BC1, C1, C2, Egress) where:
  1. Xn denotes a node in domain X, and
  1. XYn denotes a node on the border of domain X and domain Y.
 Note that Ingress is a node in domain A, and Egress is a node in
 domain C.  This is shown in Figure 1 where the domains correspond
 with areas.

Lee, et al. Standards Track [Page 4] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

         area A               area B              area C
  <-------------------> <----------------> <------------------>
 Ingress-----A1----A2----AB1----B1----B2----BC1----C1----C2----Egress
 ^  \                / | \              / | \                /
 |   \              /  |  \            /  |  \              /
 |    A3----------A4--AB2--B3--------B4--BC2--C3----------C4
 |                     ^                  ^
 |                     |                  |
 |                     |                  |
 |                     |              ERO: (C3-strict, C4-strict,
 |                     |                    Egress-strict)
 |                     |              XRO: Not needed
 |                     |
 |               ERO: (B3-strict, B4-strict, BC2-strict, Egress-loose)
 |               XRO: (BC1, C1, C2)
 |
 ERO: (A3-strict, A4-strict, AB2-strict, Egress-loose)
 XRO: (AB1, B1, B2, BC1, C1, C2, Egress)
         Figure 1: Domains Corresponding to IGP Areas
 Consider the establishment of a node-diverse protection path in the
 example above.  The protection path must avoid all nodes on the
 primary path.  The exclusions for area A are handled during
 Constrained Shortest Path First (CSPF) computation at Ingress, so the
 ERO and XRO signaled at Ingress could be (A3-strict, A4-strict,
 AB2-strict, Egress-loose) and (AB1, B1, B2, BC1, C1, C2),
 respectively.  At AB2, the ERO and XRO could be (B3-strict, B4-
 strict, BC2-strict, Egress-loose) and (BC1, C1, C2), respectively.
 At BC2, the ERO could be (C3-strict, C4-strict, Egress-strict) and an
 XRO is not needed from BC2 onwards.
 In general, consideration SHOULD be given (as with explicit route) to
 the size of signaled data and the impact on the signaling protocol.

1.3. Relationship to MPLS TE MIB

 [RFC3812] defines managed objects for managing and modeling MPLS-
 based traffic engineering.  Included in [RFC3812] is a means to
 configure explicit routes for use on specific LSPs.  This
 configuration allows the exclusion of certain resources.
 In systems where the full explicit path is not computed at the
 ingress (or at a path computation site for use at the ingress), it
 may be necessary to signal those exclusions.  This document offers a
 means of doing this signaling.

Lee, et al. Standards Track [Page 5] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

2. Shared Risk Link Groups

 The identifier of an SRLG is defined as a 32-bit quantity in
 [RFC4202].  An SRLG subobject is introduced such that it can be used
 in the exclusion methods as described in the following sections.
 This document does not assume or preclude any other usage for this
 subobject.  This subobject might also be appropriate for use within
 Explicit Route object (ERO) or Record Route object (RRO), but this is
 outside the scope of this document.

2.1. SRLG Subobject

 The new SRLG subobject is defined by this document as follows.  Its
 format is modeled on the ERO subobjects defined in [RFC3209].
  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    |       SRLG Id (4 bytes)       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      SRLG Id (continued)      |           Reserved            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    L
       The L bit is an attribute of the subobject.  The L bit is set
       if the subobject represents a loose hop in the explicit route.
       If the bit is not set, the subobject represents a strict hop in
       the explicit route.
       For exclusions (as used by XRO and EXRS defined in this
       document), the L bit SHOULD be set to zero and ignored.
    Type
       The type of the subobject (34)
    Length
       The Length contains the total length of the subobject in bytes,
       including the Type and Length fields.  The Length is always 8.
    SRLG Id
       The 32-bit identifier of the SRLG.
    Reserved
       This field is reserved.  It SHOULD be set to zero on
       transmission and MUST be ignored on receipt.

Lee, et al. Standards Track [Page 6] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

3. Exclude Route List

 The exclude route identifies a list of abstract nodes that should not
 be traversed along the path of the LSP being established.  It is
 RECOMMENDED that the size of the exclude route list be limited to a
 value local to the node originating the exclude route list.

3.1. EXCLUDE_ROUTE Object (XRO)

 Abstract nodes to be excluded from the path are specified via the
 EXCLUDE_ROUTE object (XRO).
 Currently, one C_Type is defined, Type 1 EXCLUDE_ROUTE.  The
 EXCLUDE_ROUTE object has the following format:
       Class = 232, C_Type = 1
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     //                        (Subobjects)                         //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The contents of an EXCLUDE_ROUTE object are a series of variable-
 length data items called subobjects.  This specification adapts ERO
 subobjects as defined in [RFC3209], [RFC3473], and [RFC3477] for use
 in route exclusions.  The SRLG subobject as defined in Section 2 of
 this document has not been defined before.  The SRLG subobject is
 defined here for use with route exclusions.
 The following subobject types are supported.
      Type           Subobject
      -------------+-------------------------------
      1              IPv4 prefix
      2              IPv6 prefix
      4              Unnumbered Interface ID
      32             Autonomous system number
      34             SRLG
 The defined values for Type above are specified in [RFC3209] and in
 this document.
 The concept of loose or strict hops has no meaning in route
 exclusion.  The L bit, defined for ERO subobjects in [RFC3209], is
 reused here to indicate that an abstract node MUST be excluded (value

Lee, et al. Standards Track [Page 7] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

 0) or SHOULD be avoided (value 1).  The distinction is that the path
 of an LSP must not traverse an abstract node listed in the XRO with
 the L bit clear, but may traverse one with the L bit set.  A node
 responsible for routing an LSP (for example, for expanding a loose
 hop) should attempt to minimize the number of abstract nodes listed
 in the XRO with the L bit set that are traversed by the LSP according
 to local policy.  A node generating XRO subobjects with the L bit set
 must be prepared to accept an LSP that traverses one, some, or all of
 the corresponding abstract nodes.
 Subobjects 1, 2, and 4 refer to an interface or a set of interfaces.
 An Attribute octet is introduced in these subobjects to indicate the
 attribute (e.g., interface, node, SRLG) associated with the
 interfaces that should be excluded from the path.  For instance, the
 attribute node allows a whole node to be excluded from the path by
 specifying an interface of that node in the XRO subobject, in
 contrast to the attribute interface, which allows a specific
 interface (or multiple interfaces) to be excluded from the path
 without excluding the whole node.  The attribute SRLG allows all
 SRLGs associated with an interface to be excluded from the path.

3.1.1. IPv4 Prefix 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    | IPv4 address (4 bytes)        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | IPv4 address (continued)      | Prefix Length |   Attribute   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    L
       0 indicates that the attribute specified MUST be excluded.
       1 indicates that the attribute specified SHOULD be avoided.
    Attribute
       Interface attribute values
          0 indicates that the interface or set of interfaces
          associated with the IPv4 prefix should be excluded or
          avoided.
       Node attribute value
          1 indicates that the node or set of nodes associated with
          the IPv4 prefix should be excluded or avoided.

Lee, et al. Standards Track [Page 8] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

       SRLG attribute values
          2 indicates that all the SRLGs associated with the IPv4
          prefix should be excluded or avoided.
 The rest of the fields are as defined in [RFC3209].

3.1.2. IPv6 Prefix 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    | IPv6 address (16 bytes)       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | IPv6 address (continued)                                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | IPv6 address (continued)                                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | IPv6 address (continued)                                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | IPv6 address (continued)      | Prefix Length |   Attribute   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    L
       0 indicates that the attribute specified MUST be excluded.
       1 indicates that the attribute specified SHOULD be avoided.
    Attribute
       Interface attribute value
          0 indicates that the interface or set of interfaces
          associated with the IPv6 prefix should be excluded or
          avoided.
       Node attribute value
          1 indicates that the node or set of nodes associated with
          the IPv6 prefix should be excluded or avoided.
       SRLG attribute value
          2 indicates that all the SRLGs associated with the IPv6
          prefix should be excluded or avoided.
 The rest of the fields are as defined in [RFC3209].

Lee, et al. Standards Track [Page 9] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

3.1.3. Unnumbered Interface ID 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    |    Reserved   |  Attribute    |
 | |             |               |(must be zero) |               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        TE Router ID                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Interface ID (32 bits)                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    L
       0 indicates that the attribute specified MUST be excluded.
       1 indicates that the attribute specified SHOULD be avoided.
    Attribute
       Interface attribute value
          0 indicates that the Interface ID specified should be
          excluded or avoided.
       Node attribute value
          1 indicates that the node with the Router ID should be
          excluded or avoided (this can be achieved using an IPv4/v6
          subobject as well, but is included here because it may be
          convenient to use information from subobjects of an RRO, as
          defined in [RFC3477], in specifying the exclusions).
       SRLG attribute value
          2 indicates that all the SRLGs associated with the interface
          should be excluded or avoided.
    Reserved
       This field is reserved.  It SHOULD be set to zero on
       transmission and MUST be ignored on receipt.
 The rest of the fields are as defined in [RFC3477].

3.1.4. Autonomous System Number Subobject

 The meaning of the L bit is as follows:
    0 indicates that the abstract node specified MUST be excluded.
    1 indicates that the abstract node specified SHOULD be avoided.
 The rest of the fields are as defined in [RFC3209].  There is no
 Attribute octet defined.

Lee, et al. Standards Track [Page 10] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

3.1.5. SRLG Subobject

 The meaning of the L bit is as follows:
    0 indicates that the SRLG specified MUST be excluded
    1 indicates that the SRLG specified SHOULD be avoided
 The Attribute octet is not present.  The rest of the fields are as
 defined in the "SRLG Subobject" section of this document.

3.2. Processing Rules for the EXCLUDE_ROUTE Object (XRO)

 The exclude route list is encoded as a series of subobjects contained
 in an EXCLUDE_ROUTE object.  Each subobject identifies an abstract
 node in the exclude route list.
 Each abstract node may be a precisely specified IP address belonging
 to a node, or an IP address with prefix identifying interfaces of a
 group of nodes, an Autonomous System, or an SRLG.
 The Explicit Route and routing processing is unchanged from the
 description in [RFC3209] with the following additions:
 1. When a Path message is received at a node, the node MUST check
    that it is not a member of any of the abstract nodes in the XRO if
    it is present in the Path message.  If the node is a member of any
    of the abstract nodes in the XRO with the L-flag set to "exclude",
    it SHOULD return a PathErr with the error code "Routing Problem"
    and error value of "Local node in Exclude Route".  If there are
    SRLGs in the XRO, the node SHOULD check that the resources the
    node uses are not part of any SRLG with the L-flag set to
    "exclude" that is specified in the XRO.  If it is, it SHOULD
    return a PathErr with error code "Routing Problem" and error value
    of "Local node in Exclude Route".
 2. Each subobject MUST be consistent.  If a subobject is not
    consistent then the node SHOULD return a PathErr with error code
    "Routing Problem" and error value "Inconsistent Subobject".  An
    example of an inconsistent subobject is an IPv4 Prefix subobject
    containing the IP address of a node and the attribute field is set
    to "interface" or "SRLG".
 3. The subobjects in the ERO and XRO SHOULD NOT contradict each
    other.  If a Path message is received that contains contradicting
    ERO and XRO subobjects, then:
  1. Subobjects in the XRO with the L flag not set (zero) MUST take

precedence over the subobjects in the ERO – that is, a

      mandatory exclusion expressed in the XRO MUST be honored and an

Lee, et al. Standards Track [Page 11] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

      implementation MUST reject such a Path message.  This means that
      a PathErr with error code "Routing Problem" and error value of
      "Route blocked by Exclude Route" is returned.
  1. Subobjects in the XRO with the L flag set do not take precedence

over ERO subobjects – that is, an implementation MAY choose to

      reject a Path message because of such a contradiction, but MAY
      continue and set up the LSP (ignoring the XRO subobjects that
      contradict the ERO subobjects).
 4. When choosing a next hop or expanding an explicit route to include
    additional subobjects, a node:
    a. MUST NOT introduce an explicit node or an abstract node that
       equals or is a member of any abstract node that is specified in
       the EXCLUDE_ROUTE object with the L-flag set to "exclude".  The
       number of introduced explicit nodes or abstract nodes with the
       L flag set to "avoid", which indicates that it is not mandatory
       to be excluded but that it is less preferred, SHOULD be
       minimized in the computed path.
    b. MUST NOT introduce links, nodes, or resources identified by the
       SRLG Id specified in the SRLG subobjects(s).  The number of
       introduced SRLGs with the L flag set to "avoid" SHOULD be
       minimized.
    If these rules preclude further forwarding of the Path message,
    the node SHOULD return a PathErr with the error code "Routing
    Problem" and error value of "Route blocked by Exclude Route".
    Note that the subobjects in the XRO is an unordered list of
    subobjects.
 A node receiving a Path message carrying an XRO MAY reject the
 message if the XRO is too large or complicated for the local
 implementation or the rules of local policy.  In this case, the node
 MUST send a PathErr message with the error code "Routing Error" and
 error value "XRO Too Complex".  An ingress LSR receiving this error
 code/value combination MAY reduce the complexity of the XRO or route
 around the node that rejected the XRO.
 The XRO Class-Num is of the form 11bbbbbb so that nodes that do not
 support the XRO forward it uninspected and do not apply the
 extensions to ERO processing described above.  This approach is
 chosen to allow route exclusion to traverse parts of the network that
 are not capable of parsing or handling the new function.  Note that

Lee, et al. Standards Track [Page 12] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

 Record Route may be used to allow computing nodes to observe
 violations of route exclusion and attempt to re-route the LSP
 accordingly.
 If a node supports the XRO, but not a particular subobject or part of
 that subobject, then that particular subobject is ignored.  Examples
 of a part of a subobject that can be supported are: (1) only prefix
 32 of the IPv4 prefix subobject could be supported, or (2) a
 particular subobject is supported but not the particular attribute
 field.
 When a node forwards a Path message, it can do the following three
 operations related to XRO besides the processing rules mentioned
 above:
 1. If no XRO was present, an XRO may be included.
 2. If an XRO was present, it may remove the XRO if it is sure that
    the next nodes do not need this information anymore.  An example
    is where a node can expand the ERO to a full strict path towards
    the destination.  See Figure 1 where BC2 is removing the XRO from
    the Path message.
 3. If an XRO was present, the content of the XRO can be modified.
    Subobjects can be added or removed.  See Figure 1 for an example
    where AB2 is stripping off some subobjects.
 In any case, a node MUST NOT introduce any explicit or abstract node
 in the XRO (irrespective of the value of the L flag) that it also has
 introduced in the ERO.

4. Explicit Exclusion Route

 The Explicit Exclusion Route defines abstract nodes or resources
 (such as links, unnumbered interfaces, or labels) that must not or
 should not be used on the path between two inclusive abstract nodes
 or resources in the explicit route.

4.1. Explicit Exclusion Route Subobject (EXRS)

 A new ERO subobject type is defined.  The Explicit Exclusion Route
 Subobject (EXRS) has type 33.  Although the EXRS is an ERO subobject
 and the XRO is reusing the ERO subobject, an EXRS MUST NOT be present
 in an XRO.  An EXRS is an ERO subobject that contains one or more
 subobjects of its own, called EXRS subobjects.

Lee, et al. Standards Track [Page 13] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

 The format of the EXRS is as follows:
  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    |           Reserved            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 //                one or more EXRS subobjects                  //
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    L
       It MUST be set to zero on transmission and MUST be ignored on
       receipt.  (Note: The L bit in an EXRS subobject is as defined
       for the XRO subobjects.)
    Type
       The type of the subobject (33).
    Reserved
       This field is reserved.  It SHOULD be set to zero on
       transmission and MUST be ignored on receipt.
    EXRS subobjects
       An EXRS subobject indicates the abstract node or resource to be
       excluded.  The format of an EXRS subobject is exactly the same
       as the format of a subobject in the XRO.  An EXRS may include
       all subobjects defined in this document for the XRO.
 Thus, an EXRS for an IP hop may look as follows:
   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    |           Reserved            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |L|    Type     |     Length    | IPv4 address (4 bytes)        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | IPv4 address (continued)      | Prefix Length |   Attribute   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Lee, et al. Standards Track [Page 14] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

4.2. Processing Rules for the Explicit Exclusion Route Subobject (EXRS)

 Each EXRS may carry multiple exclusions.  The exclusion is encoded
 exactly as for XRO subobjects and prefixed by an additional Type and
 Length.
 The scope of the exclusion is the step between the previous ERO
 subobject that identifies an abstract node, and the subsequent ERO
 subobject that identifies an abstract node.  The processing rules of
 the EXRS are the same as the processing rule of the XRO within this
 scope.  Multiple exclusions may be present between any pair of
 abstract nodes.
 Exclusions may indicate explicit nodes, abstract nodes, or Autonomous
 Systems that must not be traversed on the path to the next abstract
 node indicated in the ERO.
 Exclusions may also indicate resources (such as unnumbered
 interfaces, link ids, and labels) that must not be used on the path
 to the next abstract node indicated in the ERO.
 SRLGs may also be indicated for exclusion from the path to the next
 abstract node in the ERO by the inclusion of an EXRS containing an
 SRLG subobject.  If the L bit in the SRLG subobject is zero, the
 resources (nodes, links, etc.) identified by the SRLG MUST NOT be
 used on the path to the next abstract node indicated in the ERO.  If
 the L bit is set, the resources identified by the SRLG SHOULD be
 avoided.
 If a node is called upon to process an EXRS and does not support
 handling of exclusions it will behave as described in [RFC3209] when
 an unrecognized ERO subobject is encountered.  This means that this
 node will return a PathErr with error code "Routing Error" and error
 value "Bad EXPLICIT_ROUTE object" with the EXPLICIT_ROUTE object
 included, truncated (on the left) to the offending EXRS.
 If the presence of EXRS precludes further forwarding of the Path
 message, the node SHOULD return a PathErr with the error code
 "Routing Problem" and error value "Route Blocked by Exclude Route".
 A node MAY reject a Path message if the EXRS is too large or
 complicated for the local implementation or as governed by local
 policy.  In this case, the node MUST send a PathErr message with the
 error code "Routing Error" and error value "EXRS Too Complex".  An
 ingress LSR receiving this error code/value combination MAY reduce
 the complexity of the EXRS or route around the node that rejected the
 EXRS.

Lee, et al. Standards Track [Page 15] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

5. Processing of XRO together with EXRS

 When an LSR performs ERO expansion and finds both the XRO in the Path
 message and EXRS in the ERO, it MUST exclude all the SRLGs, nodes,
 links, and resources listed in both places.  Where some elements
 appear in both lists, it MUST be handled according to the stricter
 exclusion request.  That is, if one list says that an SRLG, node,
 link, or resource must be excluded, and the other says only that it
 should be avoided, then the element MUST be excluded.

6. Minimum Compliance

 An implementation MUST be at least compliant with the following:
 1. The XRO MUST be supported with the following restrictions:
  1. The IPv4 Prefix subobject MUST be supported with a prefix length

of 32, and an attribute value of "interface" and "node". Other

      prefix values and attribute values MAY be supported.
  1. The IPv6 Prefix subobject MUST be supported with a prefix length

of 128, and an attribute value of "interface" and "node". Other

      prefix values and attribute values MAY be supported.
 2. The EXRS MAY be supported.  If supported, the same restrictions as
    for the XRO apply.  If not supported, an EXRS encountered during
    normal ERO processing MUST be rejected as an unknown ERO subobject
    as described in Section 4.2.  Note that a node SHOULD NOT parse
    ahead into an ERO, and if it does, it MUST NOT reject the ERO if
    it discovers an EXRS that applies to another node.
 3. If XRO or EXRS are supported, the implementation MUST be compliant
    with the processing rules of the supported, not supported, or
    partially supported subobjects as specified within this document.

7. Security Considerations

 Security considerations for MPLS-TE and GMPLS signaling are covered
 in [RFC3209] and [RFC3473].  This document does not introduce any new
 messages or any substantive new processing, and so those security
 considerations continue to apply.
 Note that any security concerns that exist with explicit routes
 should be considered with regard to route exclusions.  For example,
 some administrative boundaries may consider explicit routes to be
 security violations and may strip EROs from the Path messages that
 they process.  In this case, the XRO should also be considered for
 removal from the Path message.

Lee, et al. Standards Track [Page 16] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

 It is possible that an arbitrarily complex XRO or EXRS sequence could
 be introduced as a form of denial-of-service attack since its
 presence will potentially cause additional processing at each node on
 the path of the LSP.  It should be noted that such an attack assumes
 that an otherwise trusted LSR (i.e., one that has been authenticated
 by its neighbors) is misbehaving.  A node that receives an XRO or
 EXRS sequence that it considers too complex according to its local
 policy may respond with a PathErr message carrying the error code
 "Routing Error" and error value "XRO Too Complex" or "EXRS Too
 Complex".

8. IANA Considerations

 It might be considered that an alternative approach would be to
 assign one of the bits of the ERO subobject type field (perhaps the
 top bit) to identify that a subobject is intended for inclusion
 rather than exclusion.  However, [RFC3209] states that the type field
 (seven bits) should be assigned as 0 - 63 through IETF consensus
 action, 64 - 95 as first come first served, and 96 - 127 are reserved
 for private use.  It would not be acceptable to disrupt existing
 implementations, so the only option would be to split the IETF
 consensus range leaving only 32 subobject types.  It is felt that 32
 would be an unacceptably small number for future expansion of the
 protocol.

8.1. New ERO Subobject Type

 IANA registry: RSVP PARAMETERS
 Subsection: Class Names, Class Numbers, and Class Types
 A new subobject has been added to the existing entry for:
 20  EXPLICIT_ROUTE
 The registry reads:
             33  Explicit Exclusion Route subobject (EXRS)
 The Explicit Exclusion Route subobject (EXRS) is defined in Section
 4.1, "Explicit Exclusion Route Subobject (EXRS)".  This subobject may
 be present in the Explicit Route Object, but not in the Route Record
 Object or in the new EXCLUDE_ROUTE object, and it should not be
 listed among the subobjects for those objects.

Lee, et al. Standards Track [Page 17] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

8.2. New RSVP-TE Class Numbers

 IANA registry: RSVP PARAMETERS
 Subsection: Class Names, Class Numbers, and Class Types
 A new class number has been added for EXCLUDE_ROUTE object (XRO) as
 defined in Section 3.1, "EXCLUDE_ROUTE Object (XRO)".
 EXCLUDE_ROUTE
 Class-Num of type 11bbbbbb
 Value: 232
 Defined CType: 1 (EXCLUDE_ROUTE)
 Subobjects 1, 2, 4, and 32 are as defined for Explicit Route Object.
 An additional subobject has been registered as requested in Section
 8.1, "New ERO Subobject Type".  The text should appear as:
 Sub-object type
              1   IPv4 address              [RFC3209]
              2   IPv6 address              [RFC3209]
              4   Unnumbered Interface ID   [RFC3477]
             32   Autonomous system number  [RFC3209]
             33   Explicit Exclusion Route subobject (EXRS) [RFC4874]
             34   SRLG                      [RFC4874]
 The SRLG subobject is defined in Section 3.1.5, "SRLG Subobject".
 The value 34 has been assigned.

8.3. New Error Codes

 IANA registry: RSVP PARAMETERS
 Subsection: Error Codes and Globally-Defined Error Value Sub-Codes
 New Error Values sub-codes have been registered for the Error Code
 'Routing Problem' (24).
   64 = Unsupported Exclude Route Subobject Type
   65 = Inconsistent Subobject
   66 = Local Node in Exclude Route
   67 = Route Blocked by Exclude Route
   68 = XRO Too Complex
   69 = EXRS Too Complex

Lee, et al. Standards Track [Page 18] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

9. Acknowledgments

 This document reuses text from [RFC3209] for the description of
 EXCLUDE_ROUTE.
 The authors would like to express their thanks to Lou Berger, Steffen
 Brockmann, Igor Bryskin, Dimitri Papadimitriou, Cristel Pelsser, and
 Richard Rabbat for their considered opinions on this document.  Also
 thanks to Yakov Rekhter for reminding us about SRLGs!
 Thanks to Eric Gray for providing GenArt review and to Ross Callon
 for his comments.

10. References

10.1. Normative References

 [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3209]   Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
             and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
             Tunnels", RFC 3209, December 2001.
 [RFC3473]   Berger, L., "Generalized Multi-Protocol Label Switching
             (GMPLS) Signaling Resource ReserVation Protocol-Traffic
             Engineering (RSVP-TE) Extensions", RFC 3473, January
             2003.
 [RFC3477]   Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
             in Resource ReSerVation Protocol - Traffic Engineering
             (RSVP-TE)", RFC 3477, January 2003.
 [RFC4202]   Kompella, K. and Y. Rekhter, "Routing Extensions in
             Support of Generalized Multi-Protocol Label Switching
             (GMPLS)", RFC 4202, October 2005.

10.2. Informative References

 [CRANKBACK] Farrel, A., Satyanarayana, A., Iwata, A., Ash, G., and S.
             Marshall-Unitt, "Crankback Signaling Extensions for MPLS
             Signaling", Work in Progress, January 2007.
 [RFC3630]   Katz, D., Kompella, K., and D. Yeung, "Traffic
             Engineering (TE) Extensions to OSPF Version 2", RFC 3630,
             September 2003.

Lee, et al. Standards Track [Page 19] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

 [RFC3784]   Smit, H. and T. Li, "Intermediate System to Intermediate
             System (IS-IS) Extensions for Traffic Engineering (TE)",
             RFC 3784, June 2004.
 [RFC3812]   Srinivasan, C., Viswanathan, A., and T. Nadeau,
             "Multiprotocol Label Switching (MPLS) Traffic Engineering
             (TE) Management Information Base (MIB)", RFC 3812, June
             2004.
 [RFC4208]   Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
             "Generalized Multiprotocol Label Switching (GMPLS) User-
             Network Interface (UNI): Resource ReserVation Protocol-
             Traffic Engineering (RSVP-TE) Support for the Overlay
             Model", RFC 4208, October 2005.
 [RFC4216]   Zhang, R. and JP. Vasseur, "MPLS Inter-Autonomous System
             (AS) Traffic Engineering (TE) Requirements", RFC 4216,
             November 2005.

Lee, et al. Standards Track [Page 20] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

Appendix A. Applications

 This section describes some applications that can make use of the
 XRO.  The intention is to show that the XRO is not an application-
 specific object, but that it can be used for multiple purposes.  In a
 few examples, other solutions might be possible for that particular
 case, but the intention is to show that a single object can be used
 for all the examples, hence making the XRO a rather generic object
 without having to define a solution and new objects for each new
 application.

A.1. Inter-Area LSP Protection

 One method to establish an inter-area LSP is where the ingress router
 selects an ABR, and then the ingress router computes a path towards
 this selected ABR such that the configured constraints of the LSP are
 fulfilled.  In the example of Figure A.1, an LSP has to be
 established from node A in area 1 to node C in area 2.  If no loose
 hops are configured, then the computed ERO at A could look as
 follows: (A1-strict, A2-strict, ABR1-strict, C-loose).  When the Path
 message arrives at ABR1, then the ERO is (ABR1-strict, C-loose), and
 it can be expanded by ABR1 to (B1-strict, ABR3-strict, C-loose).
 Similarly, at ABR3 the received ERO is (ABR3-strict, C-loose), and it
 can be expanded to (C1-strict, C2-strict, C-strict).  If a backup LSP
 also has to be established, then A takes another ABR (ABR2 in this
 case) and computes a path towards this ABR that fulfills the
 constraints of the LSP and that is disjoint from the path of the
 primary LSP.  The ERO generated by A looks as follows for this
 example: (A3-strict, A4-strict, ABR2-strict, C-loose).
 In order to let ABR2 expand the ERO, it also needs to know the path
 of the primary LSP so that the ERO expansion is disjoint from the
 path of the primary LSP.  Therefore, A also includes an XRO that at
 least contains (ABR1, B1, ABR3, C1, C2).  Based on these constraints,
 ABR2 can expand the ERO such that it is disjoint from the primary
 LSP.  In this example, the ERO computed by ABR2 would be (B2-strict,
 ABR4-strict, C-loose), and the XRO generated by B contains at least
 (ABR3, C1, C2).  The latter information is needed for ABR4 to expand
 the ERO so that the path is disjoint from the primary LSP in area 2.

Lee, et al. Standards Track [Page 21] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

          Area 1           Area 0          Area 2
     <---------------><--------------><--------------->
     +---A1---A2----ABR1-----B1-----ABR3----C1---C2---+
     |        |              |              |         |
     |        |              |              |         |
     A        |              |              |         C
     |        |              |              |         |
     |        |              |              |         |
     +---A3---A4----ABR2-----B2-----ABR4----C3---C4---+
               Figure A.1: Inter-area LSPs
 In this example, a node performing the path computation first selects
 an ABR and then computes a strict path towards this ABR.  For the
 backup LSP, all nodes of the primary LSP in the next areas have to be
 put in the XRO (with the exception of the destination node if node
 protection and no link protection is required).  When an ABR computes
 the next path segment, i.e., the path over the next area, it may
 remove the nodes from the XRO that are located in that area with the
 exception of the ABR where the primary LSP is exiting the area.  The
 latter information is still required because when the selected ABR
 (ABR4 in this example) further expands the ERO, it has to exclude the
 ABR on which the primary LSP is entering that area (ABR3 in this
 example).  This means that when ABR2 generates an XRO, it may remove
 the nodes in area 0 from the XRO but not ABR3.  Note that not doing
 this would not cause harm in this example because there is no path
 from ABR4 to C via ABR3 in area 2.  If there is a link between ABR4-
 ABR3 and ABR3-C, then it is required to have ABR3 in the XRO
 generated by ABR2.
 Discussion on the length of the XRO: When link or node protection is
 requested, the length of the XRO is bounded by the length of the RRO
 of the primary LSP.  It can be made shorter by removing nodes by the
 ingress node and the ABRs.  In the example above, the RRO of the
 primary LSP contains 8 subobjects, while the maximum XRO length can
 be bounded by 6 subobjects (nodes A1 and A2 do not have to be in the
 XRO).  For SRLG protection, the XRO has to list all SRLGs that are
 crossed by the primary LSP.

A.2. Inter-AS LSP Protection

 When an inter-AS LSP (which has to be protected by a backup LSP to
 provide link or node protection) is established, the same method as
 for the inter-area LSP case can be used.  The difference is when the
 backup LSP is not following the same AS-path as the primary LSP
 because then the XRO should always contain the full path of the
 primary LSP.  In case the backup LSP is following the same AS-path

Lee, et al. Standards Track [Page 22] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

 (but with different ASBRs -- at least in case of node protection), it
 is similar to the inter-area case: ASBRs expanding the ERO over the
 next AS may remove the XRO subobjects located in that AS.  Note that
 this can only be done by an ingress ASBR (the ASBR where the LSP is
 entering the AS).
 Discussion on the length of the XRO: the XRO is bounded by the length
 of the RRO of the primary LSP.
 Suppose that SRLG protection is required, and the ASs crossed by the
 main LSP use a consistent way of allocating SRLG-ids to the links
 (i.e., the ASs use a single SRLG space).  In this case, the SRLG-ids
 of each link used by the main LSP can be recorded by means of the
 RRO; the SRLG-ids are then used by the XRO.  If the SRLG-ids are only
 meaningful when local to the AS, putting SRLG-ids in the XRO crossing
 many ASs makes no sense.  To provide SRLG protection for inter-AS
 LSPs the link IP address of the inter-AS link used by the primary LSP
 can be put into the XRO of the Path message of the detour LSP or
 bypass tunnel.  The ASBR where the detour LSP or bypass tunnel is
 entering the AS can translate this into the list of SRLG-ids known to
 the local AS.
 Discussion on the length of the XRO: the XRO only contains 1
 subobject, which contains the IP address of the inter-AS link
 traversed by the primary LSP (assuming that the primary LSP and
 detour LSP or bypass tunnel are leaving the AS in the same area, and
 that they are also entering the next AS in the same area).

Lee, et al. Standards Track [Page 23] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

A.3. Protection in the GMPLS Overlay Model

 When an edge-node wants to establish an LSP towards another edge-node
 over an optical core network as described in [RFC4208] (see Figure
 A.2), the XRO can be used for multiple purposes.
   Overlay                                                  Overlay
   Network        +--------------------------------+        Network
 +----------+     |                                |     +----------+
 |   +----+ |     |  +-----+   +-----+   +-----+   |     | +----+   |
 |   |    | |     |  |     |   |     |   |     |   |     | |    |   |
 | --+ EN1+-+-----+--+ CN1 +---+ CN2 +---+ CN3 +---+-----+-+ EN3+-- |
 |   |    | |  +--+--+     |   |     |   |     +---+--+  | |    |   |
 |   +----+ |  |  |  +--+--+   +--+--+   +--+--+   |  |  | +----+   |
 |          |  |  |     |         |         |      |  |  |          |
 +----------+  |  |     |         |         |      |  |  +----------+
               |  |     |         |         |      |  |
 +----------+  |  |     |         |         |      |  |  +----------+
 |          |  |  |  +--+--+      |      +--+--+   |  |  |          |
 |   +----+ |  |  |  |     |      +------+     |   |  |  | +----+   |
 |   |    +-+--+  |  | CN4 +-------------+ CN5 |   |  +--+-+    |   |
 | --+ EN2+-+-----+--+     |             |     +---+-----+-+ EN4+-- |
 |   |    | |     |  +-----+             +-----+   |     | |    |   |
 |   +----+ |     |                                |     | +----+   |
 |          |     +--------------------------------+     |          |
 +----------+                 Core Network               +----------+
      Overlay                                                 Overlay
      Network                                                 Network
  Legend:
       EN - Edge-Node
       CN - Core-Node
                               Figure A.2
 A first application is where an edge-node wants to establish multiple
 LSPs towards the same destination edge-node, and these LSPs need to
 have few or no SRLGs in common.  In this case EN1 could establish an
 LSP towards EN3, and then it can establish a second LSP listing all
 links used by the first LSP with the indication to avoid the SRLGs of
 these links.  This information can be used by CN1 to compute a path
 for the second LSP.  If the core network consists of multiple areas,
 then the SRLG-ids have to be listed in the XRO.  The same example
 applies to nodes and links.

Lee, et al. Standards Track [Page 24] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

 Another application is where the edge-node wants to set up a backup
 LSP that is also protecting the links between the edge-nodes and
 core-nodes.  For instance, when EN2 establishes an LSP to EN4, it
 sends a Path message to CN4, which computes a path towards EN4 over
 (for instance) CN5.  When EN2 gets back the RRO of that LSP, it can
 signal a new LSP to CN1 with EN4 as the destination and the XRO
 computed based on the RRO of the first LSP.  Based on this
 information, CN1 can compute a path that has the requested diversity
 properties (e.g., a path going over CN2 and CN3, and then to EN4).
 It is clear that in these examples, the core-node may not alter the
 RRO in a Resv message to make its only contents be the subobjects
 from the egress core-node through the egress edge-node.

A.4. LSP Protection inside a Single Area

 The XRO can also be used inside a single area.  Take for instance a
 network where the TE extensions of the IGPs as described in [RFC3630]
 and [RFC3784] are not used.  Hence, each node has to select a next-
 hop and possibly crankback [CRANKBACK] has to be used when there is
 no viable next-hop.  In this case, when signaling a backup LSP, the
 XRO can be put in the Path message to exclude the links, nodes, or
 SRLGs of the primary LSP.  An alternative way to provide this
 functionality would be to indicate the following in the Path message
 of the backup LSP: the primary LSP and which type of protection is
 required.  This latter solution would work for link and node
 protection, but not for SRLG protection.
 When link or node protection is requested, the XRO is of the same
 length as the RRO of the primary LSP.  For SRLG protection, the XRO
 has to list all SRLGs that are crossed by the primary LSP.  Note that
 for SRLG protection, the link IP address to reference the SRLGs of
 that link cannot be used since the TE extensions of the IGPs are not
 used in this example.  Hence, a node cannot translate any link IP
 address located in that area to its SRLGs.

Lee, et al. Standards Track [Page 25] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

Authors' Addresses

 Cheng-Yin Lee
 EMail: c.yin.lee@gmail.com
 Adrian Farrel
 Old Dog Consulting
 Phone: +44 (0) 1978 860944
 EMail: adrian@olddog.co.uk
 Stefaan De Cnodder
 Alcatel-Lucent
 Copernicuslaan 50
 B-2018 Antwerp
 Belgium
 Phone: +32 3 240 85 15
 EMail: stefaan.de_cnodder@alcatel-lucent.be

Lee, et al. Standards Track [Page 26] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007

Full Copyright Statement

 Copyright (C) The IETF Trust (2007).
 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.
 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, THE IETF TRUST 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.

Intellectual Property

 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.

Acknowledgement

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

Lee, et al. Standards Track [Page 27]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4874.txt · Last modified: 2007/04/04 18:04 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki