draft-ietf-ccamp-inter-domain-rsvp-te-07.txt   rfc5151.txt 
INTERNET-DRAFT A. Farrel (Editor)
Network Working Group Old Dog Consulting
Intended Status: Standards Track
Updates: RFC 3209, RFC 3473 A. Ayyangar
Expires: March 2008 Juniper Networks
Network Working Group A. Farrel, Ed.
Request for Comments: 5151 Old Dog Consulting
Updates: 3209, 3473 A. Ayyangar
Category: Standards Track Juniper Networks
JP. Vasseur JP. Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
February 2008
September 2007 Inter-Domain MPLS and GMPLS Traffic Engineering --
Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions
Inter domain Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions
draft-ietf-ccamp-inter-domain-rsvp-te-07.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 Status of This Memo
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/shadow.html. 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.
Abstract Abstract
This document describes procedures and protocol extensions for the This document describes procedures and protocol extensions for the
use of Resource ReserVation Protocol Traffic Engineering (RSVP-TE) use of Resource Reservation Protocol-Traffic Engineering (RSVP-TE)
signaling in Multiprotocol Label Switching Traffic Engineering signaling in Multiprotocol Label Switching-Traffic Engineering
(MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and
non-packet networks to support the establishment and maintenance of non-packet networks to support the establishment and maintenance of
Label Switched Paths that cross domain boundaries. Label Switched Paths that cross domain boundaries.
For the purpose of this document, a domain is considered to be any For the purpose of this document, a domain is considered to be any
collection of network elements within a common realm of address space collection of network elements within a common realm of address space
or path computation responsibility. Examples of such domains include or path computation responsibility. Examples of such domains include
Autonomous Systems, IGP routing areas, and GMPLS overlay networks. Autonomous Systems, Interior Gateway Protocol (IGP) routing areas,
and GMPLS overlay networks.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction ....................................................3
1.1 Conventions Used In This Document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document ..........................3
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology ................................................4
2. Signaling Overview . . . . . . . . . . . . . . . . . . . . . 4 2. Signaling Overview ..............................................4
2.1 Signaling Options . . . . . . . . . . . . . . . . . . . . 5 2.1. Signaling Options ..........................................5
3. Procedures on the Domain Border Node . . . . . . . . . . . . . 6 3. Procedures on the Domain Border Node ............................6
3.1 Rules on ERO Processing . . . . . . . . . . . . . . . . . 7 3.1. Rules on ERO Processing ....................................8
3.2 LSP Setup Failure and Crankback . . . . . . . . . . . . . 9 3.2. LSP Setup Failure and Crankback ...........................10
3.3 RRO Processing Across Domains . . . . . . . . . . . . . . 10 3.3. RRO Processing across Domains .............................11
3.4 Notify Message Processing . . . . . . . . . . . . . . . . 10 3.4. Notify Message Processing .................................11
4. RSVP-TE Signaling Extensions . . . . . . . . . . . . . . . . . 11 4. RSVP-TE Signaling Extensions ...................................12
4.1 Control of Downstream Choice of Signaling Method . . . . . 11 4.1. Control of Downstream Choice of Signaling Method ..........12
5. Protection and Recovery of Inter-Domain TE LSPs . . . . . . . 12 5. Protection and Recovery of Inter-Domain TE LSPs ................13
5.1 Fast Recovery Support Using MPLS-TE Fast Reroute . . . . . 12 5.1. Fast Recovery Support Using MPLS-TE Fast Reroute (FRR) ....14
5.1.1 Failure Within a Domain (Link or Node Failure) . . . . 13 5.1.1. Failure within a Domain (Link or Node Failure) .....14
5.1.2 Failure of Link at Domain Borders . . . . . . . . . . 13 5.1.2. Failure of Link at Domain Border ...................14
5.1.3 Failure of a Border Node . . . . . . . . . . . . . . . 13 5.1.3. Failure of a Border Node ...........................15
5.2 Protection and Recovery of GMPLS LSPs . . . . . . . . . . 14 5.2. Protection and Recovery of GMPLS LSPs .....................15
6. Re-Optimization of Inter-Domain TE LSPs . . . . . . . . . . . 14 6. Reoptimization of Inter-Domain TE LSPs .........................16
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 16 7. Backward Compatibility .........................................17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations ........................................18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations ............................................20
9.1 Attribute Flags for LSP_Attributes Object . . . . . . . . 18 9.1. Attribute Flags for LSP_Attributes Object .................20
9.2 New Error Codes . . . . . . . . . . . . . . . . . . . . . 19 9.2. New Error Codes ...........................................20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgments ...............................................21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References ....................................................21
11.1 Normative References . . . . . . . . . . . . . . . . . . 19 11.1. Normative References ....................................21
11.2 Informative References . . . . . . . . . . . . . . . . . 20 11.2. Informative References ..................................22
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The requirements for inter-area and inter-AS Multiprotocol Label The requirements for inter-area and inter-AS (Autonomous System)
Switching (MPLS) Traffic Engineering (TE) are stated in [RFC4105] and Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) are
[RFC4216] respectively. Many of these requirements also apply to stated in [RFC4105] and [RFC4216], respectively. Many of these
Generalized MPLS (GMPLS) networks. The framework for inter-domain requirements also apply to Generalized MPLS (GMPLS) networks. The
MPLS-TE is provided in [RFC4726]. framework for inter-domain MPLS-TE is provided in [RFC4726].
This document presents procedures and extensions to Resource This document presents procedures and extensions to Resource
Reservation Protocol Traffic Engineering (RSVP-TE) signaling for the Reservation Protocol-Traffic Engineering (RSVP-TE) signaling for the
setup and maintenance of traffic engineered Label Switched Paths (TE setup and maintenance of traffic engineered Label Switched Paths (TE
LSPs) that span multiple domains in MPLS-TE or GMPLS networks. The LSPs) that span multiple domains in MPLS-TE or GMPLS networks. The
signaling procedures described in this document are applicable to signaling procedures described in this document are applicable to
MPLS-TE packet LSPs established using RSVP-TE ([RFC3209]) and all MPLS-TE packet LSPs established using RSVP-TE ([RFC3209]) and all
LSPs (packet and non-packet) that use RSVP-TE GMPLS extensions as LSPs (packet and non-packet) that use RSVP-TE GMPLS extensions as
described in [RFC3473]. described in [RFC3473].
Three different signaling methods for inter-domain RSVP-TE signaling Three different signaling methods for inter-domain RSVP-TE signaling
are identified in [RFC4726]. Contiguous LSPs are are identified in [RFC4726]. Contiguous LSPs are achieved using the
achieved using the procedures of [RFC3209] and [RFC3473] to create a procedures of [RFC3209] and [RFC3473] to create a single end-to-end
single end-to-end LSP that spans all domains. Nested LSPs are LSP that spans all domains. Nested LSPs are established using the
established using the techniques described in [RFC4206] to carry the techniques described in [RFC4206] to carry the end-to-end LSP in a
end-to-end LSP in a separate tunnel across each domain. Stitched LSPs separate tunnel across each domain. Stitched LSPs are established
are established using the procedures of [LSP-STITCHING] to construct using the procedures of [RFC5150] to construct an end-to-end LSP from
an end-to-end LSP from the concatenation of separate LSPs each the concatenation of separate LSPs each spanning a domain.
spanning a domain.
This document defines the RSVP-TE protocol extensions necessary to This document defines the RSVP-TE protocol extensions necessary to
control and select which of the three signaling mechanisms is used control and select which of the three signaling mechanisms is used
for any one end-to-end inter-domain TE LSP. for any one end-to-end inter-domain TE LSP.
For the purpose of this document, a domain is considered to be any For the purpose of this document, a domain is considered to be any
collection of network elements within a common realm of address space collection of network elements within a common realm of address space
or path computation responsibility. Examples of such domains include or path computation responsibility. Examples of such domains include
Autonomous Systems, IGP areas, and GMPLS overlay networks Autonomous Systems, IGP areas, and GMPLS overlay networks
([RFC4208]). ([RFC4208]).
1.1. Conventions Used In This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Terminology 1.2. Terminology
AS: Autonomous System. AS: Autonomous System.
ASBR: Autonmous System Border Router. A router used to connect ASBR: Autonomous System Border Router. A router used to connect
together ASes of a different or the same Service Provider via one or together ASs of a different or the same Service Provider via one or
more Inter-AS links. more inter-AS links.
Bypass Tunnel: An LSP that is used to protect a set of LSPs passing Bypass Tunnel: An LSP that is used to protect a set of LSPs passing
over a common facility. over a common facility.
ERO: Explicit Route Object. ERO: Explicit Route Object.
FA: Forwarding Adjacency. FA: Forwarding Adjacency.
LSR: Label Switching Router. LSR: Label Switching Router.
skipping to change at page 4, line 29 skipping to change at page 4, line 52
next section: next section:
- contiguous LSPs - contiguous LSPs
- nested LSPs - nested LSPs
- stitched LSPs. - stitched LSPs.
In fact, as pointed out in [RFC4726], any combination of these three In fact, as pointed out in [RFC4726], any combination of these three
options may be used in the course of an end-to-end inter-domain LSP. options may be used in the course of an end-to-end inter-domain LSP.
That is, the options should be considered as per-domain transit That is, the options should be considered as per-domain transit
options so that an end-to-end inter-domain LSP that starts in domain options so that an end-to-end inter-domain LSP that starts in domain
A, transits domains B, C and D, and ends in domain E might use an LSP A, transits domains B, C, and D, and ends in domain E might use an
that runs contiguously from the ingress in domain A, through domain B LSP that runs contiguously from the ingress in domain A, through
to the border with domain C. Domain C might be transited using the domain B to the border with domain C. Domain C might be transited
nested LSP option to reach the border with domain D, and domain D using the nested LSP option to reach the border with domain D, and
might be transited using the stitched LSP option to reach the border domain D might be transited using the stitched LSP option to reach
with domain E, from where a normal LSP runs to the egress. the border with domain E, from where a normal LSP runs to the egress.
This document describes the RSVP-TE signaling extensions required to This document describes the RSVP-TE signaling extensions required to
control which of the three signaling mechanisms is used and to select select and control which of the three signaling mechanisms is used.
which of the three signaling mechanisms is used.
The specific protocol extensions required to signal each LSP type are The specific protocol extensions required to signal each LSP type are
described in other documents and are out of scope for this document. described in other documents and are out of scope for this document.
Similarly, the routing extensions and path computation techniques Similarly, the routing extensions and path computation techniques
necessary for the establishment of inter-domain LSPs are out of necessary for the establishment of inter-domain LSPs are out of
scope. An implementation of a transit LSR is unaware of the options scope. An implementation of a transit LSR is unaware of the options
for inter-domain TE LSPs since it sees only TE LSPs. An for inter-domain TE LSPs since it sees only TE LSPs. An
implementation of a domain border LSR has to decide what mechanisms implementation of a domain border LSR has to decide what mechanisms
of inter-domain TE LSP support to include, but must in any case of inter-domain TE LSP support to include, but must in any case
support contiguous inter-domain TE LSPs since this is the default support contiguous inter-domain TE LSPs since this is the default
skipping to change at page 5, line 14 skipping to change at page 5, line 35
2.1. Signaling Options 2.1. Signaling Options
There are three ways in which an RSVP-TE LSP could be signaled across There are three ways in which an RSVP-TE LSP could be signaled across
multiple domains: multiple domains:
Contiguous Contiguous
A contiguous TE LSP is a single TE LSP that is set up across A contiguous TE LSP is a single TE LSP that is set up across
multiple domains using RSVP-TE signaling procedures described in multiple domains using RSVP-TE signaling procedures described in
[RFC3209] and [RFC3473]. No additional TE LSPs are required to [RFC3209] and [RFC3473]. No additional TE LSPs are required to
create a contiguous TE LSP and the same RSVP-TE information for create a contiguous TE LSP, and the same RSVP-TE information for
the TE LSP is maintained along the entire LSP path. In particular, the TE LSP is maintained along the entire LSP path. In
the TE LSP has the same RSVP-TE session and LSP ID at every LSR particular, the TE LSP has the same RSVP-TE session and LSP ID at
along its path. every LSR along its path.
Nesting Nested
One or more TE LSPs may be nested within another TE LSP as One or more TE LSPs may be nested within another TE LSP as
described in [RFC4206]. This technique can be used to nest one described in [RFC4206]. This technique can be used to nest one or
or more inter-domain TE LSPs into an intra-domain hierarchical LSP more inter-domain TE LSPs into an intra-domain hierarchical LSP
(H-LSP). The label stacking construct is used to achieve nesting (H-LSP). The label stacking construct is used to achieve nesting
in packet networks. In the rest of this document, the term H-LSP in packet networks. In the rest of this document, the term H-LSP
is used to refer to an LSP that allows other LSPs to be nested is used to refer to an LSP that allows other LSPs to be nested
within it. An H-LSP may be advertised as a TE link within the same within it. An H-LSP may be advertised as a TE link within the
instance of the routing protocol as was used to advertise the TE same instance of the routing protocol as was used to advertise the
links from which it was created, in which case it is a Forwarding TE links from which it was created, in which case it is a
Adjacency (FA) [RFC4206]. Forwarding Adjacency (FA) [RFC4206].
Stitching Stitched
The concept of LSP stitching as well as the required signaling The concept of LSP stitching as well as the required signaling
procedures is described in [LSP-STITCHING]. This technique can be procedures are described in [RFC5150]. This technique can be used
used to stitch together shorter LSPs (LSP segments) to create a to stitch together shorter LSPs (LSP segments) to create a single,
single, longer LSP. The LSP segments of an inter-domain LSP may be longer LSP. The LSP segments of an inter-domain LSP may be
intra-domain LSPs or inter-domain LSPs. intra-domain LSPs or inter-domain LSPs.
The process of stitching in the data plane results in a single, The process of stitching in the data plane results in a single,
end-to-end contiguous LSP. But in the control plane each segment is end-to-end contiguous LSP. But in the control plane, each segment
signaled as a separate LSP (with distinct RSVP sessions) and the is signaled as a separate LSP (with distinct RSVP sessions) and
end-to-end LSP is signaled as yet another LSP with its own RSVP the end-to-end LSP is signaled as yet another LSP with its own
session. Thus the control plane operation for LSP stitching is very RSVP session. Thus, the control plane operation for LSP stitching
similar to that for nesting. is very similar to that for nesting.
An end-to-end inter-domain TE LSP may be achieved using one or more An end-to-end inter-domain TE LSP may be achieved using one or more
of the signaling techniques described. The choice is a matter of of the signaling techniques described. The choice is a matter of
policy for the node requesting LSP setup (the ingress) and policy for policy for the node requesting LSP setup (the ingress) and policy for
each successive domain border node. On receipt of an LSP setup each successive domain border node. On receipt of an LSP setup
request (RSVP-TE Path message) for an inter-domain TE LSP, the request (RSVP-TE Path message) for an inter-domain TE LSP, the
decision of whether to signal the LSP contiguously or whether to nest decision of whether to signal the LSP contiguously or whether to nest
or stitch it to another TE LSP, depends on the parameters signaled or stitch it to another TE LSP depends on the parameters signaled
from the ingress node and on the configuration of the local node. from the ingress node and on the configuration of the local node.
The stitching segment LSP or H-LSP used to cross a domain may be The stitching segment LSP or H-LSP used to cross a domain may be
pre-established or signaled dynamically based on the demand caused by pre-established or signaled dynamically based on the demand caused by
the arrival of the inter-domain TE LSP setup request. the arrival of the inter-domain TE LSP setup request.
3. Procedures on the Domain Border Node 3. Procedures on the Domain Border Node
Whether an inter-domain TE LSP is contiguous, nested, or stitched is Whether an inter-domain TE LSP is contiguous, nested, or stitched is
limited by the signaling methods supported by or configured on the limited by the signaling methods supported by or configured on the
intermediate nodes, and it is usually the domain border nodes where intermediate nodes. It is usually the domain border nodes where this
this restriction applies since other transit nodes are oblivious to restriction applies since other transit nodes are oblivious to the
the mechanism in use. The ingress of the LSP may further restrict the mechanism in use. The ingress of the LSP may further restrict the
choice by setting parameters in the Path message when it is signaled. choice by setting parameters in the Path message when it is signaled.
When a domain border node receives the RSVP Path message for an When a domain border node receives the RSVP Path message for an
inter-domain TE LSP setup, it MUST carry out the following procedures 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 before it can forward the Path message to the next node along the
path: path:
1. Apply policies for the domain and the domain border node. These 1. Apply policies for the domain and the domain border node.
policies may restrict the establishment of inter-domain TE LSPs. These policies may restrict the establishment of inter-domain
In case of a policy failure, the node SHOULD fail the setup and TE LSPs. In case of a policy failure, the node SHOULD fail
send a PathErr message with error code "Policy control failure"/ the setup and send a PathErr message with error code "Policy
"Inter-domain policy failure". control failure"/ "Inter-domain policy failure".
2. Determine the signaling method to be used to cross the domain. 2. Determine the signaling method to be used to cross the domain.
If the ingress node of the inter-domain TE LSP has specified If the ingress node of the inter-domain TE LSP has specified
restrictions on the methods to be used, these MUST be adhered restrictions on the methods to be used, these MUST be adhered
to. Within the freedom allowed by the ingress node, the domain to. Within the freedom allowed by the ingress node, the
border node MAY choose any method according to local domain border node MAY choose any method according to local
configuration and policies. If no resultant signaling method is configuration and policies. If no resultant signaling method
available or allowed, the domain border node MUST send a PathErr is available or allowed, the domain border node MUST send a
message with an error code as described in Section 4.1. PathErr message with an error code as described in Section
4.1.
Thus, for example, an ingress may request a contiguous LSP Thus, for example, an ingress may request a contiguous LSP
because it wishes to exert maximal control over the LSP's path because it wishes to exert maximal control over the LSP's path
and to control when re-optimization takes place. But the and to control when reoptimization takes place. But the
operator of a transit domain may decide (for example) that only operator of a transit domain may decide (for example) that
LSP stitching is allowed for exactly the reason that it gives only LSP stitching is allowed for exactly the reason that it
the operator the chance to reoptimize their own domain under gives the operator the chance to reoptimize their own domain
their own control. In this case, the policy applied at the entry under their own control. In this case, the policy applied at
to the transit domain will result in the return of a PathErr the entry to the transit domain will result in the return of a
message and the ingress has a choice to: PathErr message and the ingress has a choice to:
- find another path avoiding the transit domain
- relax his requirements - find another path avoiding the transit domain,
- relax his requirements, or
- fail to provide the service. - fail to provide the service.
3. Carry out ERO procedures as described in Section 3 in addition 3. Carry out ERO procedures as described in Section 3 in addition
to the procedures in [RFC3209] and [RFC3473]. to the procedures in [RFC3209] and [RFC3473].
4. Perform any path computations as required to determine the path 4. Perform any path computations as required to determine the
across the domain and potentially to select the exit point from path across the domain and potentially to select the exit
the domain. point from the domain.
The path computation procedure is outside the scope of this The path computation procedure is outside the scope of this
document. A path computation option is specified in document. A path computation option is specified in
[INTER-DOMAIN-PD-PATH-COMP], and another option is to use a [RFC5152], and another option is to use a Path Computation
Path Computation Element (PCE) [RFC4655]. Element (PCE) [RFC4655].
4a. In the case of nesting or stitching, either find an existing 4a. In the case of nesting or stitching, either find an
intra-domain TE LSP to carry the inter-domain TE LSP or existing intra-domain TE LSP to carry the inter-domain TE
signal a new one, depending on local policy. LSP or signal a new one, depending on local policy.
In event of a path computation failure, a PathErr message SHOULD In the event of a path computation failure, a PathErr message
be sent with error code "Routing Problem" using an error value SHOULD be sent with error code "Routing Problem" using an
selected according to the reason for computation failure. A error value selected according to the reason for computation
domain border node MAY opt so silently discard the Path message failure. A domain border node MAY opt to silently discard the
in this case as described in Section 8. Path message in this case as described in Section 8.
In the event of the receipt of a PathErr message reporting In the event of the receipt of a PathErr message reporting signaling
signaling failure from within the domain or reported from a failure from within the domain or reported from a downstream domain,
downstream domain, the domain border node MAY apply crankback the domain border node MAY apply crankback procedures as described in
procedures as described in Section 3.2. If crankback is not Section 3.2. If crankback is not applied, or is exhausted, the
applied, or is exhausted, the border node MUST continue with border node MUST continue with PathErr processing as described in
PathErr processing as described in [RFC3209] and [RFC3473]. [RFC3209] and [RFC3473].
In the event of successful processing of a Path or Resv message, In the event of successful processing of a Path or Resv message, the
the domain border node MUST carry out RRO procedures as described domain border node MUST carry out RRO procedures as described in
in Section 3.3. Section 3.3.
3.1. Rules on ERO Processing 3.1. Rules on ERO Processing
The ERO that a domain border node receives in the Path message was The ERO that a domain border node receives in the Path message was
supplied by the ingress node of the TE LSP and may have been updated supplied by the ingress node of the TE LSP and may have been updated
by other nodes (for example, other domain border nodes) as the Path by other nodes (for example, other domain border nodes) as the Path
message was propagated. The content of the ERO depends on several message was propagated. The content of the ERO depends on several
factors including: factors including:
- the path computation techniques used - the path computation techniques used,
- the degree of TE visibility available to the nodes performing - the degree of TE visibility available to the nodes performing path
path computation computation, and
- policy at the nodes creating/modifying the ERO. - the policy at the nodes creating/modifying the ERO.
In general, H-LSPs and LSP segments are used between domain border In general, H-LSPs and LSP segments are used between domain border
nodes, but there is no restriction on the use of such LSPs to span nodes, but there is no restriction on the use of such LSPs to span
multiple hops entirely within a domain. Therefore, the discussion multiple hops entirely within a domain. Therefore, the discussion
that follows may be equally applied to any node within a domain that follows may be equally applied to any node within a domain
although the term 'domain border node' continues to be used for although the term "domain border node" continues to be used for
clarity. clarity.
When a Path message reaches the domain border node, the following When a Path message reaches the domain border node, the following
rules apply for ERO processing and for further signaling. rules apply for ERO processing and for further signaling.
1. If there are any policies related to ERO processing for the 1. If there are any policies related to ERO processing for the
LSP, they MUST be applied and corresponding actions taken. For LSP, they MUST be applied and corresponding actions MUST be
example, there might be a policy to reject EROs that identify taken. For example, there might be a policy to reject EROs
nodes within the domain. In case of inter-domain LSP setup that identify nodes within the domain. In case of
failures due to policy failures related to ERO processing, the inter-domain LSP setup failures due to policy failures related
node SHOULD issue a PathErr with error code "Policy control to ERO processing, the node SHOULD issue a PathErr with error
failure"/"Inter-domain explicit route rejected", but MAY be code "Policy control failure"/"Inter-domain explicit route
configured to silently discard the Path message or to return a rejected", but MAY be configured to silently discard the Path
different error code for security reasons. message or to return a different error code for security
reasons.
2. Section 8.2 of [RFC4206] describes how a node at the edge of a 2. Section 8.2 of [RFC4206] describes how a node at the edge of a
region processes the ERO in the incoming Path message and uses region 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 this ERO, to either find an existing H-LSP or signal a new
using the ERO hops. This process includes adjusting the ERO H-LSP using the ERO hops. This process includes adjusting the
before sending the Path message to the next hop. These ERO before sending the Path message to the next hop. These
procedures MUST be followed for nesting or stitching of procedures MUST be followed for nesting or stitching of
inter-domain TE LSPs. inter-domain TE LSPs.
3. If an ERO subobject identifies a TE link formed by the 3. If an ERO subobject identifies a TE link formed by the
advertisement of an H-LSP or LSP segment (whether numbered or advertisement of an H-LSP or LSP segment (whether numbered or
unnumbered), contiguous signaling MUST NOT be used. The node MUST unnumbered), contiguous signaling MUST NOT be used. The node
either use nesting or stitching according to the capabilities of MUST use either nesting or stitching according to the
the LSP that forms the TE link, the parameters signaled in the capabilities of the LSP that forms the TE link, the parameters
Path message, and local policy. If there is a conflict between the signaled in the Path message, and local policy. If there is a
capabilities of the LSP that forms the TE link indicated in the conflict between the capabilities of the LSP that forms the TE
ERO and the parameters on the Path message, the domain border node link indicated in the ERO and the parameters on the Path
SHOULD send a PathErr with error code "Routing Problem"/"ERO message, the domain border node SHOULD send a PathErr with
conflicts with inter-domain signaling method", but MAY be error code "Routing Problem"/"ERO conflicts with inter-domain
configured to silently discard the Path message or to return a signaling method", but MAY be configured to silently discard
different error code for security reasons. the Path message or to return a different error code for
security reasons.
4. An ERO in a Path message received by a domain border node may 4. An ERO in a Path message received by a domain border node may
have a loose hop as the next hop. This may be an IP address or have a loose hop as the next hop. This may be an IP address
an AS number. In such cases, the ERO MUST be expanded to or an AS number. In such cases, the ERO MUST be expanded to
determine the path to the next hop using some form of path determine the path to the next hop using some form of path
computation that may, itself, generate loose hops. computation that may, itself, generate loose hops.
5. In the absence of any ERO subobjects beyond the local domain 5. In the absence of any ERO subobjects beyond the local domain
border node, the LSP egress (the destination encoded in the RSVP border node, the LSP egress (the destination encoded in the
Session object) MUST be considered as the next loose hop and RSVP Session object) MUST be considered as the next loose hop
rule 4 applied. and rule 4 applied.
6. In the event of any other failures processing the ERO, a PathErr 6. In the event of any other failures processing the ERO, a
message SHOULD be sent as described in [RFC3209] or [RFC3473], but PathErr message SHOULD be sent as described in [RFC3209] or
a domain border router MAY be configured to silently discard the [RFC3473], but a domain border router MAY be configured to
Path message or to return a different error code for security silently discard the Path message or to return a different
reasons. error code for security reasons.
3.2. LSP Setup Failure and Crankback 3.2. LSP Setup Failure and Crankback
When an error occurs during LSP setup a PathErr message is sent back When an error occurs during LSP setup, a PathErr message is sent back
towards the LSP ingress node to report the problem. If the LSP towards the LSP ingress node to report the problem. If the LSP
traverses multiple domains, this PathErr will be seen successively by traverses multiple domains, this PathErr will be seen successively by
each domain border node. each domain border node.
Domain border nodes MAY apply local policies to restrict the Domain border nodes MAY apply local policies to restrict the
propagation of information about the contents of the domain. For propagation of information about the contents of the domain. For
example, a domain border node MAY replace the information in a example, a domain border node MAY replace the information in a
PathErr message that indicates a specific failure at a specific node PathErr message that indicates a specific failure at a specific node
with information that reports a more general error with the entire with information that reports a more general error with the entire
domain. These procedures are similar to those described for the domain. These procedures are similar to those described for the
skipping to change at page 9, line 43 skipping to change at page 10, line 43
LSP setup failure, a domain border node MAY hold the PathErr and make LSP setup failure, a domain border node MAY hold the PathErr and make
further attempts to establish the LSP if allowed by local policy and further attempts to establish the LSP if allowed by local policy and
by the parameters signaled on the Path message for the LSP. Such by the parameters signaled on the Path message for the LSP. Such
attempts might involve the computation of alternate routes through attempts might involve the computation of alternate routes through
the domain, or the selection of different downstream domains. If a the domain, or the selection of different downstream domains. If a
subsequent attempt is successful, the domain border router MUST subsequent attempt is successful, the domain border router MUST
discard the held PathErr message, but if all subsequent attempts are discard the held PathErr message, but if all subsequent attempts are
unsuccessful, the domain border router MUST send the PathErr upstream unsuccessful, the domain border router MUST send the PathErr upstream
toward the ingress node. In this latter case, the domain border toward the ingress node. In this latter case, the domain border
router MAY change the information in the PathErr message to provide router MAY change the information in the PathErr message to provide
further crankback details and information aggregation as described further crankback details and information aggregation as described in
in [RFC4920]. [RFC4920].
Crankback rerouting MAY also be used to handle the failure of LSPs Crankback rerouting MAY also be used to handle the failure of LSPs
after they have been established [RFC4920]. after they have been established [RFC4920].
3.3. RRO Processing Across Domains 3.3. RRO Processing across Domains
[RFC3209] defines the RRO as an optional used for loop detection and [RFC3209] defines the RRO as an optional object used for loop
for providing information about the hops traversed by LSPs. detection and for providing information about the hops traversed by
LSPs.
As described for overlay networks in [RFC4208], a domain border node As described for overlay networks in [RFC4208], a domain border node
MAY filter or modify the information provided in an RRO for MAY filter or modify the information provided in an RRO for
confidentiality reasons according to local policy. For example, a confidentiality reasons according to local policy. For example, a
series of identifiers of hops within a domain MAY be replaced with series of identifiers of hops within a domain MAY be replaced with
the domain identifier (such as the AS number) or be removed entirely the domain identifier (such as the AS number) or be removed entirely
leaving just the domain border nodes. leaving just the domain border nodes.
Note that a domain border router MUST NOT mask its own presence, and Note that a domain border router MUST NOT mask its own presence, and
MUST include itself in the RRO. MUST include itself in the RRO.
Such filtering of RRO information does not hamper the working of the Such filtering of RRO information does not hamper the working of the
signaling protocol, but the subsequent information loss may render signaling protocol, but the subsequent information loss may render
management diagnostic procedures inoperable or at least make them management diagnostic procedures inoperable or at least make them
more complicated requiring the coordination of administrators of more complicated, requiring the coordination of administrators of
multiple domains. multiple domains.
Similarly protocol procedures that depend on the presence of RRO Similarly, protocol procedures that depend on the presence of RRO
information may become inefficient. For example, the fast reroute information may become inefficient. For example, the Fast Reroute
procedures defined in [RFC4090] use information in the RRO to procedures defined in [RFC4090] use information in the RRO to
determine the labels to use and the downstream MP. determine the labels to use and the downstream MP.
3.4. Notify Message Processing 3.4. Notify Message Processing
Notify messages are introduced in [RFC3473]. They may be sent direct Notify messages are introduced in [RFC3473]. They may be sent direct
rather than hop-by-hop, and so may speed the propagation of error rather than hop-by-hop, and so may speed the propagation of error
information. If a domain border router is interested in seeing information. If a domain border router is interested in seeing such
such messages (for example, to enable it to provide protection messages (for example, to enable it to provide protection switching),
switching), it is RECOMMENDED that the domain border router update it is RECOMMENDED that the domain border router update the Notify
the Notify Request objects in the Path and Resv messages to show its Request objects in the Path and Resv messages to show its own address
own address following the procedures of [RFC3473]. following the procedures of [RFC3473].
Note that the replacement of a Notify Recipient in the Notify Request Note that the replacement of a Notify Recipient in the Notify Request
object means that some Notify messages (for example, those intended object means that some Notify messages (for example, those intended
for delivery to the ingress LSR) may need to be examined, processed for delivery to the ingress LSR) may need to be examined, processed,
and forwarded at domain borders. This is an obvious trade-off issue and forwarded at domain borders. This is an obvious trade-off issue
as the ability to handle notifiable events locally (i.e. within the as the ability to handle notifiable events locally (i.e., within the
domain) may or may not outweigh the cost of processing and forwarding domain) may or may not outweigh the cost of processing and forwarding
Notify messages beyond the domain. Observe that the cost increases Notify messages beyond the domain. Observe that the cost increases
linearly with the number of domains in use. linearly with the number of domains in use.
Also note that, as described in section 8, a domain administrator may Also note that, as described in Section 8, a domain administrator may
wish to filter or modify Notify messages that are generated within a wish to filter or modify Notify messages that are generated within a
domain in order to preserve security or confidentiality of network domain in order to preserve security or confidentiality of network
information. This is most easily achieved if the Notify messages are information. This is most easily achieved if the Notify messages are
sent via the domain borders. sent via the domain borders.
4. RSVP-TE Signaling Extensions 4. RSVP-TE Signaling Extensions
The following RSVP-TE signaling extensions are defined to enable The following RSVP-TE signaling extensions are defined to enable
inter-domain LSP setup. inter-domain LSP setup.
4.1. Control of Choice of Signaling Method 4.1. Control of Choice of Signaling Method
In many network environments there may be a network-wide policy that In many network environments, there may be a network-wide policy that
determines which one of the three inter-domain LSP techniques is determines which one of the three inter-domain LSP techniques is
used. In these cases, no protocol extensions are required. used. In these cases, no protocol extensions are required.
However, in environments that support more than one technique, an However, in environments that support more than one technique, an
ingress node may wish to constrain the choice made by domain border ingress node may wish to constrain the choice made by domain border
nodes for each inter-domain TE LSP that it originates. nodes for each inter-domain TE LSP that it originates.
[RFC4420] defines the LSP_Attributes object that can be used to [RFC4420] defines the LSP_Attributes object that can be used to
signal required attributes of an LSP. The Attributes Flags TLV signal required attributes of an LSP. The Attributes Flags TLV
includes Boolean flags that define individual attributes. includes Boolean flags that define individual attributes.
This document defines a new bit in the TLV that can be set by the This document defines a new bit in the TLV that can be set by the
ingress node of an inter-domain TE LSP to restrict the intermediate ingress node of an inter-domain TE LSP to restrict the intermediate
nodes to using contiguous signaling. nodes to using contiguous signaling:
Contiguous LSP bit (bit number assignment in Section 9.1). Contiguous LSP bit (bit number assignment in Section 9.1)
This flag is set by the ingress node that originates a Path message This flag is set by the ingress node that originates a Path message
to set up an inter-domain TE LSP if it requires that the contiguous to set up an inter-domain TE LSP if it requires that the contiguous
LSP technique is used. This flag bit is only to be used in the LSP technique is used. This flag bit is only to be used in the
Attributes Flags TLV. Attributes Flags TLV.
When a domain border LSR receives a Path message containing this bit When a domain border LSR receives a Path message containing this bit
set (one), the node MUST NOT perform stitching or nesting in support set (one), the node MUST NOT perform stitching or nesting in support
of the inter-domain TE LSP being set up. When this bit is clear of the inter-domain TE LSP being set up. When this bit is clear
(zero), a domain border LSR MAY perform stitching or nesting (zero), a domain border LSR MAY perform stitching or nesting
skipping to change at page 12, line 24 skipping to change at page 13, line 36
forward the object unmodified. forward the object unmodified.
The choice of action by an ingress node that receives a PathErr when The choice of action by an ingress node that receives a PathErr when
requesting the use of a contiguous LSP is out of the scope of this requesting the use of a contiguous LSP is out of the scope of this
document, but may include the computation of an alternate path. document, but may include the computation of an alternate path.
5. Protection and Recovery of Inter-Domain TE LSPs 5. Protection and Recovery of Inter-Domain TE LSPs
The procedures described in Sections 3 and 4 MUST be applied to all The procedures described in Sections 3 and 4 MUST be applied to all
inter-domain TE LSPs, including bypass tunnels, detour LSPs inter-domain TE LSPs, including bypass tunnels, detour LSPs
[RFC4090], and segment recovery LSPs [RFC4873]. This means that these [RFC4090], and segment recovery LSPs [RFC4873]. This means that
LSPs will also be subjected to ERO processing, policies, path these LSPs will also be subjected to ERO processing, policies, path
computation, etc. computation, etc.
Note also that the paths for these backup LSPs needs to be either Note also that the paths for these backup LSPs need to be either
pre-configured, computed and signaled with the protected LSP, or pre-configured, computed, and signaled with the protected LSP or
computed on-demand at the PLR. Just as with any inter-domain TE LSP, computed on-demand at the PLR. Just as with any inter-domain TE LSP,
the ERO may comprise of strict or loose hops, and will depend on the the ERO may comprise strict or loose hops and will depend on the TE
TE visibility of the computation point into the subsequent domain. visibility of the computation point into the subsequent domain.
If loose hops are required created in the path of the backup LSP, ERO If loose hops are present in the path of the backup LSP, ERO
expansion will be required at some point along the path: probably at expansion will be required at some point along the path: probably at
a domain border node. In order that the backup path remains disjoint a domain border node. In order that the backup path remains disjoint
from the protected LSP(s) the node performing the ERO expansion must from the protected LSP(s) the node performing the ERO expansion must
be provided with the path of the protected LSPs between the PLR and be provided with the path of the protected LSPs between the PLR and
the MP. This information can be gathered from the RROs of the the MP. This information can be gathered from the RROs of the
protected LSPs and is signaled in the DETOUR object for Fast Reroute protected LSPs and is signaled in the DETOUR object for Fast Reroute
[RFC4090], and using route exclusion [RFC4874] for other protection [RFC4090] and uses route exclusion [RFC4874] for other protection
schemes. schemes.
5.1. Fast Recovery Support Using MPLS-TE Fast Reroute (FRR) 5.1. Fast Recovery Support Using MPLS-TE Fast Reroute (FRR)
[RFC4090] describes two methods for local protection for a [RFC4090] describes two methods for local protection for a packet TE
packet TE LSP in case of link, SRLG, or node failure. This section LSP in case of link, Shared Risk Link Group (SRLG), or node failure.
describes how these mechanisms work with the proposed signaling This section describes how these mechanisms work with the proposed
solutions for inter-domain TE LSP setup. signaling solutions for inter-domain TE LSP setup.
5.1.1. Failure Within a Domain (Link or Node Failure) 5.1.1. Failure within a Domain (Link or Node Failure)
The mode of operation of MPLS-TE Fast Reroute to protect a The mode of operation of MPLS-TE Fast Reroute to protect a
contiguous, stitched or nested TE LSP within a domain is identical to contiguous, stitched, or nested TE LSP within a domain is identical
the existing procedures described in [RFC4090]. Note that, in the to the existing procedures described in [RFC4090]. Note that, in the
case of nesting or stitching, the end-to-end LSP is automatically case of nesting or stitching, the end-to-end LSP is automatically
protected by the protection operation performed on the H-LSP or protected by the protection operation performed on the H-LSP or
stitching segment LSP. stitching segment LSP.
No protocol extensions are required. No protocol extensions are required.
5.1.2. Failure of a Link at a Domain Borders 5.1.2. Failure of a Link at a Domain Border
This cases arises where two domains are connected by a TE link. In This case arises where two domains are connected by a TE link. In
this case each domain has its own domain border node, and these two this case, each domain has its own domain border node, and these two
nodes are connected by the TE link. An example of this case is where nodes are connected by the TE link. An example of this case is where
the ASBRs of two ASes are connected by a TE link. the ASBRs of two ASs are connected by a TE link.
A contiguous LSP can be backed up using any PLR and MP, but if the A contiguous LSP can be backed up using any PLR and MP, but if the
LSP uses stitching or nesting in either of the connected domains, the LSP uses stitching or nesting in either of the connected domains, the
PLR and MP MUST be domain border nodes for those domains. It will be PLR and MP MUST be domain border nodes for those domains. It will be
usual to attempt to use the local (connected by the failed link) usual to attempt to use the local (connected by the failed link)
domain border nodes as the PLR and MP. domain border nodes as the PLR and MP.
To protect an inter-domain link with MPLS-TE Fast Reroute, a set of To protect an inter-domain link with MPLS-TE Fast Reroute, a set of
backup tunnels must be configured or dynamically computed between the backup tunnels must be configured or dynamically computed between the
PLR and MP such that they are diversely routed from the protected PLR and MP such that they are diversely routed from the protected
skipping to change at page 13, line 47 skipping to change at page 15, line 13
analyzing the RROs in the Resv messages of the available bypass analyzing the RROs in the Resv messages of the available bypass
tunnels and the protected TE LSP. It may be helpful to this process tunnels and the protected TE LSP. It may be helpful to this process
if the extensions defined in [RFC4561] are used to clearly if the extensions defined in [RFC4561] are used to clearly
distinguish nodes and links in the RROs. distinguish nodes and links in the RROs.
5.1.3. Failure of a Border Node 5.1.3. Failure of a Border Node
Two border node failure cases exist. If the domain border falls on a Two border node failure cases exist. If the domain border falls on a
link as described in the previous section, the border node at either link as described in the previous section, the border node at either
end of the link may fail. Alternatively, if the border falls on a end of the link may fail. Alternatively, if the border falls on a
border node (as is the case with IGP areas) that single border node border node (as is the case with IGP areas), that single border node
may fail. may fail.
It can be seen that if stitching or nesting are used, the failed node It can be seen that if stitching or nesting is used, the failed node
will be the start or end (or both) or a stitching segment LSP or will be the start or end (or both) of a stitching segment LSP or
H-LSP in which case, protection must be provided to the far end of H-LSP, in which case protection must be provided to the far end of
stitching segment or H-LSP. Thus, where one of these two techniques the stitching segment or H-LSP. Thus, where one of these two
is in use, the PLR will be the upstream domain entry point in the techniques is in use, the PLR will be the upstream domain entry point
case of the failure of the domain exit point, and the MP will be the in the case of the failure of the domain exit point, and the MP will
downstream domain exit point in the case of the failure of the be the downstream domain exit point in the case of the failure of the
domain entry point. Where the domain border falls at a single domain domain entry point. Where the domain border falls at a single domain
border node, both cases will apply. border node, both cases will apply.
If the contiguous LSP mechanism is in use, normal selection of the If the contiguous LSP mechanism is in use, normal selection of the
PLR and MP can be applied and any node within the domains may be used PLR and MP can be applied, and any node within the domains may be
to fill these roles. used to fill these roles.
As before, selection of a suitable backup tunnel (in this case an As before, selection of a suitable backup tunnel (in this case, an
NNHOP backup) must consider the paths of the backed up LSPs and the NNHOP backup) must consider the paths of the backed-up LSPs and the
available NNHOP tunnels by examination of their RROs. available NNHOP tunnels by examination of their RROs.
Note that where the PLR is not immediately upstream of the failed Note that where the PLR is not immediately upstream of the failed
node, error propagation time may be delayed unless some mechanism node, error propagation time may be delayed unless some mechanism
such as [BFD-MPLS] is implemented, or unless direct reporting, such such as [BFD-MPLS] is implemented or unless direct reporting, such as
as through the GMPLS Notify message [RFC3473] is employed. through the GMPLS Notify message [RFC3473], is employed.
5.2. Protection and Recovery of GMPLS LSPs 5.2. Protection and Recovery of GMPLS LSPs
[RFC4873] describes GMPLS based segment recovery. This allows [RFC4873] describes GMPLS-based segment recovery. This allows
protection against a span failure, a node failure, or failure over protection against a span failure, a node failure, or failure over
any particular portion of a network used by an LSP. any particular portion of a network used by an LSP.
The domain border failure cases described in Section 5.1 may also The domain border failure cases described in Section 5.1 may also
occur in GMPLS networks (including packet networks) and can be occur in GMPLS networks (including packet networks) and can be
protected against using segment protection without any additional protected against using segment protection without any additional
protocol extensions. protocol extensions.
Note that if loose hops are used in the construction of the working Note that if loose hops are used in the construction of the working
and protection paths signaled for segment protection then care is and protection paths signaled for segment protection, then care is
required to keep these paths disjoint. If the paths are signaled required to keep these paths disjoint. If the paths are signaled
incrementally then route exclusion [RFC4874] may be used to ensure incrementally, then route exclusion [RFC4874] may be used to ensure
that the paths are disjoint. Otherwise a coordinated path computation that the paths are disjoint. Otherwise, a coordinated path
technique such as that offered by cooperating Path Computation computation technique such as that offered by cooperating Path
Elements [RFC4655] can provide suitable paths. Computation Elements [RFC4655] can provide suitable paths.
6. Re-Optimization of Inter-Domain TE LSPs 6. Reoptimization of Inter-Domain TE LSPs
Re-optimization of a TE LSP is the process of moving the LSP from the Reoptimization of a TE LSP is the process of moving the LSP from the
current path to a more prefered path. This involves the determination current path to a more preferred path. This involves the
of the preferred path and make-before-break signaling procedures determination of the preferred path and make-before-break signaling
[RFC3209] to minimize traffic disruption. procedures [RFC3209] to minimize traffic disruption.
Re-optimization of an inter-domain TE LSP may require a new path in Reoptimization of an inter-domain TE LSP may require a new path in
more than one domain. more than one domain.
The nature of the inter-domain LSP setup mechanism defines how The nature of the inter-domain LSP setup mechanism defines how
re-optimization can be applied. If the LSP is contiguous then the reoptimization can be applied. If the LSP is contiguous, then the
signaling of the make-before-break process MUST be initiated by the signaling of the make-before-break process MUST be initiated by the
ingress node as defined in [RFC3209]. But if the re-optimization is ingress node as defined in [RFC3209]. But if the reoptimization is
limited to a change in path within one domain (that is, if there is limited to a change in path within one domain (that is, if there is
no change to the domain border nodes) and nesting or stitching are in no change to the domain border nodes) and nesting or stitching is in
use, the H-LSP or stitching segment may be independently re-optimized use, the H-LSP or stitching segment may be independently reoptimized
within the domain without impacting the end-to-end LSP. within the domain without impacting the end-to-end LSP.
In all cases, however, the ingress LSR may wish to exert control and In all cases, however, the ingress LSR may wish to exert control and
coordination over the re-optimization process. For example, a transit coordination over the reoptimization process. For example, a transit
domain may be aware of the potential for reoptimization, but not domain may be aware of the potential for reoptimization, but not
bother because it is not worried by the level of service being bother because it is not worried by the level of service being
provided across the domain. But the cummulative effect on the provided across the domain. But the cumulative effect on the
end-to-end LSP may cause the head-end to worry and trigger an end-to-end LSP may cause the head-end to worry and trigger an
end-to-end reoptimization request (of course, the transit domain may end-to-end reoptimization request (of course, the transit domain may
choose to ignore the request). choose to ignore the request).
Another benefit to end-to-end reoptimization over per-domain Another benefit of end-to-end reoptimization over per-domain
reoptimization for non-contiguous inter-domain LSPs is that reoptimization for non-contiguous inter-domain LSPs is that
per-domain re-optimization is restricted to preserve the domain entry per-domain reoptimization is restricted to preserve the domain entry
and exit points (since to do otherwise would break the LSP!). But and exit points (since to do otherwise would break the LSP!). But
end-to-end reoptimization is more flexible and can select new domain end-to-end reoptimization is more flexible and can select new domain
border LSRs. border LSRs.
There may be different cost benefit analysis considerations to choose There may be different cost-benefit analysis considerations between
between end-to-end reoptimization and per-domain reoptimization. The end-to-end reoptimization and per-domain reoptimization. The greater
greater the number of hops involved in the reoptimization, the higher the number of hops involved in the reoptimization, the higher the
the risk of traffic disruption. The shorter the segment reoptimized, risk of traffic disruption. The shorter the segment reoptimized, the
the lower the chance of making a substantial improvement on the lower the chance of making a substantial improvement on the quality
qulaity of the end-to-end LSP. Administrative policies should be of the end-to-end LSP. Administrative policies should be applied in
applied in this area with care. this area with care.
[RFC4736] describes mechanisms that allow: [RFC4736] describes mechanisms that allow:
- The ingress node to request each node with a loose next hop to - The ingress node to request each node with a loose next hop to
re-evaluate the current path in order to search for a more optimal re-evaluate the current path in order to search for a more optimal
path. path.
- A node with a loose next hop to inform the ingress node that a - A node with a loose next hop to inform the ingress node that a
better path exists. better path exists.
These mechanisms SHOULD be used for re-optimization of a contiguous These mechanisms SHOULD be used for reoptimization of a contiguous
inter-domain TE LSP. inter-domain TE LSP.
Note that end-to-end reoptimization may involve a non-local Note that end-to-end reoptimization may involve a non-local
modification and that might select new entry / exit points. In this modification that might select new entry / exit points. In this
case, we can observe that local reoptimization is more easily and case, we can observe that local reoptimization is more easily and
flexibly achieved using nesting or stitching. Further, the "locality flexibly achieved using nesting or stitching. Further, the "locality
principle" (i.e., the idea of keeping information only where it is principle" (i.e., the idea of keeping information only where it is
needed) is best achieved using stitching or nesting. That said, a needed) is best achieved using stitching or nesting. That said, a
contiguous LSP can easily be modified to take advantage of local contiguous LSP can easily be modified to take advantage of local
reoptimizations (as defined in [RFC4736]) even if this would require reoptimizations (as defined in [RFC4736]) even if this would require
the dissemination of information and the invocation of signaling the dissemination of information and the invocation of signaling
outside the local domain. outside the local domain.
7. Backward Compatibility 7. Backward Compatibility
The procedures in this document are backward compatible with existing The procedures in this document are backward compatible with existing
deployments. deployments.
- Ingress LSRs are not required to support the extensions in this - Ingress LSRs are not required to support the extensions in this
document to provision intra-domain LSPs. The default behavior by document to provision intra-domain LSPs. The default behavior by
transit LSRs that receive a Path message that does not have the transit LSRs that receive a Path message that does not have the
"Contiguous LSP" bit set in the Attributes Flags TLV of the "Contiguous LSP" bit set in the Attributes Flags TLV of the
LSP_Attribtes object or does not even have the object present is LSP_Attributes object or does not even have the object present is
to allow all modes of inter-domain TE LSP, so back-level ingress to allow all modes of inter-domain TE LSP, so back-level ingress
LSRs are able to initiate inter-domain LSPs. LSRs are able to initiate inter-domain LSPs.
- Transit, non-border LSRs are not required to perform any special - Transit, non-border LSRs are not required to perform any special
processing and will pass the LSP_Attributes object onwards processing and will pass the LSP_Attributes object onwards
unmodified according to the rules of [RFC2205]. Thus back-level unmodified according to the rules of [RFC2205]. Thus, back-level
transit LSRs are fully supported. transit LSRs are fully supported.
- Domain border LSRs will need to be upgraded before inter-domain - Domain border LSRs will need to be upgraded before inter-domain TE
TE LSPs are allowed. This is because of the need to establish LSPs are allowed. This is because of the need to establish policy,
policy, administrative, and security controls before permitting administrative, and security controls before permitting
inter-domain LSPs to be signaled across a domain border. Thus inter-domain LSPs to be signaled across a domain border. Thus,
legacy domain border LSRs do not need to be considered. legacy domain border LSRs do not need to be considered.
The RRO additions in this document are fully backward compatible. The RRO additions in this document are fully backward compatible.
8. Security Considerations 8. Security Considerations
RSVP does not currently provide for automated key management. RSVP does not currently provide for automated key management.
[RFC4107] states a requirement for mandatory automated key management [RFC4107] states a requirement for mandatory automated key management
under certain situations. There is work starting in the IETF to under certain situations. There is work starting in the IETF to
define improved authentication including automated key management for define improved authentication including automated key management for
RSVP. Implementations and deployments of RSVP should pay attention to RSVP. Implementations and deployments of RSVP should pay attention
any capabilities and requirements that are outputs from this ongoing to any capabilities and requirements that are outputs from this
work. ongoing work.
A separate document is being prepared to examine the security aspects A separate document is being prepared to examine the security aspects
of RSVP-TE signaling with special reference to multi-domain of RSVP-TE signaling with special reference to multi-domain scenarios
scenarios [MPLS-GMPLS-SEC]. [RFC4726] provides an overview of the [MPLS-SEC]. [RFC4726] provides an overview of the requirements for
requirements for security in an MPLS-TE or GMPLS multi-domain security in an MPLS-TE or GMPLS multi-domain environment.
environment.
Before electing to utilise inter-domain signaling for MPLS-TE, the Before electing to utilize inter-domain signaling for MPLS-TE, the
administrators of neighboring domains MUST satisfy themselves of the administrators of neighboring domains MUST satisfy themselves as to
existence of a suitable trust relationship between the domains. In the existence of a suitable trust relationship between the domains.
the absence of such a relationship, the administrators SHOULD decide In the absence of such a relationship, the administrators SHOULD
not to deploy inter-domain signaling, and SHOULD disable RSVP-TE on decide not to deploy inter-domain signaling, and SHOULD disable
any inter-domain interfaces. RSVP-TE on any inter-domain interfaces.
When signaling an inter-domain RSVP-TE LSP, an operator MAY make use When signaling an inter-domain RSVP-TE LSP, an operator MAY make use
of the security features already defined for RSVP-TE [RFC3209]. This of the security features already defined for RSVP-TE [RFC3209]. This
may require some coordination between the domains to share the keys may require some coordination between the domains to share the keys
(see [RFC2747] and [RFC3097]), and care is required to ensure that (see [RFC2747] and [RFC3097]), and care is required to ensure that
the keys are changed sufficiently frequently. Note that this may the keys are changed sufficiently frequently. Note that this may
involve additional synchronization, should the domain border nodes involve additional synchronization, should the domain border nodes be
be protected with FRR, since the MP and PLR should also share the protected with FRR, since the MP and PLR should also share the key.
key.
For an inter-domain TE LSP, especially when it traverses different For an inter-domain TE LSP, especially when it traverses different
administrative or trust domains, the following mechanisms SHOULD be administrative or trust domains, the following mechanisms SHOULD be
provided to an operator (also see [RFC4216]): provided to an operator (also see [RFC4216]):
1) A way to enforce policies and filters at the domain borders 1) A way to enforce policies and filters at the domain borders to
to process the incoming inter-domain TE LSP setup requests process the incoming inter-domain TE LSP setup requests (Path
(Path messages) based on certain agreed trust and service messages) based on certain agreed trust and service
levels/contracts between domains. Various LSP attributes levels/contracts between domains. Various LSP attributes such as
such as bandwidth, priority, etc. could be part of such a bandwidth, priority, etc. could be part of such a contract.
contract.
2) A way for the operator to rate-limit LSP setup requests 2) A way for the operator to rate-limit LSP setup requests or error
or error notifications from a particular domain. notifications from a particular domain.
3) A mechanism to allow policy-based outbound RSVP message 3) A mechanism to allow policy-based outbound RSVP message processing
processing at the domain border node, which may involve at the domain border node, which may involve filtering or
filtering or modification of certain addresses in RSVP modification of certain addresses in RSVP objects and messages.
objects and messages.
Additionally, an operator may wish to reduce the signaling Additionally, an operator may wish to reduce the signaling
interactions between domains to improve security. For example, the interactions between domains to improve security. For example, the
operator might not trust the neighboring domain to supply correct or operator might not trust the neighboring domain to supply correct or
trustable restart information [RSVP-RESTART] and might ensure that trustable restart information [RFC5063] and might ensure that the
the availablity of restart function is not configured in the Hello availability of restart function is not configured in the Hello
message exchange across the domain border. Thus, suitable message exchange across the domain border. Thus, suitable
configuration MUST be provided in an RSVP-TE implementation to configuration MUST be provided in an RSVP-TE implementation to enable
enable the operator to control optional protocol features that may be the operator to control optional protocol features that may be
considered a security risk. considered a security risk.
Some examples of the policies described above are as follows: Some examples of the policies described above are as follows:
A) An operator may choose to implement some kind of ERO filtering A) An operator may choose to implement some kind of ERO filtering
policy on the domain border node to disallow or ignore hops policy on the domain border node to disallow or ignore hops
within the domain from being identified in the ERO of an within the domain from being identified in the ERO of an
incoming Path message. That is, the policy is that a node incoming Path message. That is, the policy is that a node
outside the domain cannot specify the path of the LSP inside the outside the domain cannot specify the path of the LSP inside the
domain. The domain border LSR can make implement this policy in domain. The domain border LSR can make implement this policy in
one of two ways: one of two ways:
- It can reject the Path message. - It can reject the Path message.
- It can ignore the hops in the ERO that lie within the domain. - It can ignore the hops in the ERO that lie within the
domain.
B) In order to preserve confidentiality of network topology, an B) In order to preserve confidentiality of network topology, an
operator may choose to disallow recording of hops within the operator may choose to disallow recording of hops within the
domain in the RRO or may choose to filter out certain recorded domain in the RRO or may choose to filter out certain recorded
RRO addresses at the domain border node. RRO addresses at the domain border node.
C) An operator may require the border node to modify the addresses C) An operator may require the border node to modify the addresses
of certain messages like PathErr or Notify originated from hops of certain messages like PathErr or Notify originated from hops
within the domain. within the domain.
D) In the event of a path computation failure, an operator may D) In the event of a path computation failure, an operator may
require the border node to silently discard the Path message require the border node to silently discard the Path message
instead of returning a PathErr. This is because a Path message instead of returning a PathErr. This is because a Path message
could be interpretted as a network probe, and a PathErr provides could be interpreted as a network probe, and a PathErr provides
information about the network capabilities and policies. information about the network capabilities and policies.
Note that the detailed specification of such policies and their Note that the detailed specification of such policies and their
implementation are outside the scope of this document. implementation are outside the scope of this document.
OAM mechanisms including [BFD-MPLS] and [RFC4379] are commonly used Operations, Administration, and Management (OAM) mechanisms including
to verify he connectivity of end-to-end LSPs and to trace their [BFD-MPLS] and [RFC4379] are commonly used to verify the connectivity
paths. Where the LSPs are inter-domain LSPs, such OAM techniques MAY of end-to-end LSPs and to trace their paths. Where the LSPs are
require to be intercepted or modified at domain borders, or to be inter-domain LSPs, such OAM techniques MAY require that OAM messages
passed transparently across domains. Further discussion of this topic are intercepted or modified at domain borders, or are passed
can be found in [INTERAS-PING] and [MPLS-GMPLS-SEC]. transparently across domains. Further discussion of this topic can
be found in [INTERAS-PING] and [MPLS-SEC].
9. IANA Considerations 9. IANA Considerations
IANA is requested to make the codepoint allocations described in the IANA has made the codepoint allocations described in the following
following sections. sections.
9.1. Attribute Flags for LSP_Attributes Object 9.1. Attribute Flags for LSP_Attributes Object
A new bit is to be allocated from the "Attributes Flags" sub-registry A new bit has been allocated from the "Attributes Flags" sub-registry
of the "RSVP TE Parameters" registry. of the "RSVP TE Parameters" registry.
Path Resv RRO Bit | Name | Attribute | Path | RRO | Reference
Bit Name message message sub-object No | | Flags Path | Flags Resv | |
---- ------------------------------- -------- -------- ---------- ----+----------------------+------------+------------+-----+----------
XX Contiguous LSP Yes No Yes 4 Contiguous LSP Yes No Yes [RFC5150]
The value XX is to be defined by IANA. A value of 4 is suggested.
9.2. New Error Codes 9.2. New Error Codes
New RSVP error codes/values are required to be allocated from the New RSVP error codes/values have been allocated from the "Error Codes
"Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry and Globally-Defined Error Value Sub-Codes" sub-registry of the "RSVP
of the "RSVP Parameters" registry. Parameters" registry.
For the existing error code "Policy control failure" (value 2), two For the existing error code "Policy control failure" (value 2), two
new error values are suggested as follows. The values are suggested new error values have been registered as follows:
and are for IANA determination.
103 = Inter-domain policy failure 103 = Inter-domain policy failure
104 = Inter-domain explicit route rejected 104 = Inter-domain explicit route rejected
For the existing error code "Routing Problem" (value 24), two new For the existing error code "Routing Problem" (value 24), two new
error values are suggested as follows. The values are suggested and error values have been registered as follows:
are for IANA determination.
21 = Contiguous LSP type not supported 28 = Contiguous LSP type not supported
22 = ERO conflicts with inter-domain signaling method 29 = ERO conflicts with inter-domain signaling method
10. Acknowledgements 10. Acknowledgements
The authors would like to acknowledge the input and helpful comments The authors would like to acknowledge the input and helpful comments
from Kireeti Kompella on various aspects discussed in the document. from Kireeti Kompella on various aspects discussed in the document.
Deborah Brungard and Dimitri Papdimitriou provided thorough reviews. Deborah Brungard and Dimitri Papdimitriou provided thorough reviews.
Thanks to Sam Hartman for detailed discussions of the security Thanks to Sam Hartman for detailed discussions of the security
considerations. considerations.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S.,
"Resource ReSerVation Protocol (RSVP) -- Version 1, and S. Jamin, "Resource ReSerVation Protocol (RSVP)
Functional Specification", RFC 2205, September 1997. -- Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC3209] Awduche, D., et al, "Extensions to RSVP for LSP Tunnels", [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
RFC 3209, December 2001. V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., et al, "Generalized Multi-Protocol Label [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol - Switching (GMPLS) Signaling Resource ReserVation
Traffic Engineering (RSVP-TE) Extensions", RFC 3473, Protocol-Traffic Engineering (RSVP-TE) Extensions",
January 2003. RFC 3473, January 2003.
[RFC4206] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths
MPLS TE", RFC 4206, October 2005. (LSP) Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE)", RFC
4206, October 2005.
[RFC4420] Farrel, A., et al, "Encoding of Attributes for [RFC4420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P.,
Multiprotocol Label Switching (MPLS) Label Switched Path and A. Ayyangar, "Encoding of Attributes for
(LSP) Establishment Using RSVP-TE", RFC 4420, February Multiprotocol Label Switching (MPLS) Label Switched
2006. Path (LSP) Establishment Using Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE)", RFC 4420,
February 2006.
[LSP-STITCHING] Ayyangar, A., Kompella, K., and Vasseur, JP., "Label [RFC5150] Ayyangar, A., Kompella, K., and JP. Vasseur, "Label
Switched Path Stitching with Generalized MPLS Traffic Switched Path Stitching with Generalized
Engineering", draft-ietf-ccamp-lsp-stitching, (work in Multiprotocol Label Switching Traffic Engineering
progress). (GMPLS TE)", RFC 5150, February 2008.
11.2. Informative References 11.2. Informative References
[RFC2747] Baker, F., Lindell, B., and Talwar, B., "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Authentication", RFC 2747, January 2000. Cryptographic Authentication", RFC 2747, January
2000.
[RFC3097] Braden, R., and Zhang, L., "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097,
April 2001.
[RFC4090] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
for LSP Tunnels", RFC 4090, May 2005. Authentication -- Updated Message Type Value", RFC
3097, April 2001.
[RFC4105] LeRoux, JL., Vasseur, JP., Boyle, J., et al, "Requirements [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed.,
for Inter-Area MPLS Traffic Engineering", RFC 4105, June "Fast Reroute Extensions to RSVP-TE for LSP Tunnels",
2005. RFC 4090, May 2005.
[RFC4107] Bellovin, S. and Housley, R., "Guidelines for Cryptographic [RFC4105] Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J.
Key Management", BCP 107, RFC 4107, June 2005. Boyle, Ed., "Requirements for Inter-Area MPLS Traffic
Engineering", RFC 4105, June 2005.
[RFC4208] G. Swallow et al, "GMPLS UNI: RSVP-TE Support for the [RFC4107] Bellovin, S. and R. Housley, "Guidelines for
Overlay Model", RFC 4208, October 2005. Cryptographic Key Management", BCP 107, RFC 4107,
June 2005.
[RFC4216] Zhang, R., et al, "MPLS Inter-Autonomous System (AS) [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y.
Traffic Engineering (TE) Requirements", RFC 4216, November 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. 2005.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol [RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-
Label Switched (MPLS) Data Plane Failures", RFC 4379, Autonomous System (AS) Traffic Engineering (TE)
February 2006. Requirements", RFC 4216, November 2005.
[RFC4561] Vasseur, JP., Ali, Z., and Sivabalan, S., "Definition of a [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-
Record Route Object (RRO) Node-Id Sub-Object", RFC 4561, Protocol Label Switched (MPLS) Data Plane Failures",
June 2006. RFC 4379, February 2006.
[RFC4655] Ash, G., Farrel, A., and Vasseur, JP., "Path Computation [RFC4561] Vasseur, J.-P., Ed., Ali, Z., and S. Sivabalan,
Element (PCE)-Based Architecture", RFC 4655, August 2006. "Definition of a Record Route Object (RRO) Node-Id
Sub-Object", RFC 4561, June 2006.
[RFC4726] Farrel, A., Vasseur, J.P., and Ayyangar, A., "A [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Framework for Inter-Domain Multiprotocol Label Switching Computation Element (PCE)-Based Architecture", RFC
Traffic Engineering", RFC 4726, November 2006. 4655, August 2006.
[RFC4736] Vasseur, JP., et al, "Reoptimization of Multiprotocol Label [RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A
Switching (MPLS) Traffic Engineering (TE) Loosely Routed Framework for Inter-Domain Multiprotocol Label
Label Switched Path (LSP)", RFC 4736, November 2006. Switching Traffic Engineering", RFC 4726, November
2006.
[RFC4873] Berger, L., et al, "GMPLS Based Segment Recovery", [RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang,
RFC 4873, May 2007. "Reoptimization of Multiprotocol Label Switching
(MPLS) Traffic Engineering (TE) Loosely Routed Label
Switched Path (LSP)", RFC 4736, November 2006.
[RFC4874] Lee, CY., Farrel, A., and De Cnodder, S., "Exclude Routes - [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A.
Extension to Resource ReserVation Protocol-Traffic Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4920] Farrel, A., et al, "Crankback Signaling Extensions for [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude
MPLS and GMPLS RSVP-TE", RFC 4920, July 2007. Routes - Extension to Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[BFD-MPLS] Aggarwal, R., et al, "BFD For MPLS LSPs", [RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A.,
draft-ietf-bfd-mpls, (work in progress). Fujita, N., and G. Ash, "Crankback Signaling
Extensions for MPLS and GMPLS RSVP-TE", RFC 4920,
July 2007.
[INTERAS-PING] Nadeau, T., and Swallow, G., "Detecting MPLS Data [BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G.
Plane Failures in Inter-AS and inter-provider Scenarios", Swallow, "BFD For MPLS LSPs", Work in Progress,
draft-nadeau-mpls-interas-lspping, work in progress. February 2005.
[INTER-DOMAIN-PD-PATH-COMP] Vasseur, JP., Ayyangar, A., and [INTERAS-PING] Nadeau, T. and G. Swallow, "Detecting MPLS Data Plane
Zhang, R., "A Per-domain path computation method for Failures in Inter-AS and inter-provider Scenarios",
computing Inter-domain Traffic Engineering (TE) Label Work in Progress, October 2006.
Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-
path-comp, (work in progress).
[MPLS-GMPLS-SEC] Luyuan Fang, et al., "Security Framework for MPLS [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang,
and GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls- "A Per-Domain Path Computation Method for
security-framework, work in progress. Establishing Inter-Domain Traffic Engineering (TE)
Label Switched Paths (LSPs)", RFC 5152, February
2008.
[RSVP-RESTART] Satyanarayana, A., and Rahman, R., "Extensions to [MPLS-SEC] Fang, L., Ed., Behringer, M., Callon, R., Le Roux, J.
GMPLS RSVP Graceful Restart", draft-ietf-ccamp-rsvp- L., Zhang, R., Knight, P., Stein, Y., Bitar, N., and
restart-ext, work in progress. R. Graveman., "Security Framework for MPLS and GMPLS
Networks", Work in Progress, July 2007.
12. Authors' Addresses [RFC5063] Satyanarayana, A., Ed., and R. Rahman, Ed.,
"Extensions to GMPLS Resource Reservation Protocol
(RSVP) Graceful Restart", RFC 5063, October 2007.
Authors' Addresses
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
E-mail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Arthi Ayyangar Arthi Ayyangar
Juniper Networks, Inc. Juniper Networks
1194 N.Mathilda Ave 1194 N. Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
E-mail: arthi@juniper.net EMail: arthi@juniper.net
Jean Philippe Vasseur Jean Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough , MA - 01719 Boxborough , MA - 01719
USA USA
Email: jpv@cisco.com EMail: jpv@cisco.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. 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, 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.
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.
 End of changes. 141 change blocks. 
417 lines changed or deleted 432 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/