draft-ietf-ccamp-inter-domain-framework-04.txt   draft-ietf-ccamp-inter-domain-framework-05.txt 
Network Working Group Adrian Farrel Network Working Group Adrian Farrel
IETF Internet Draft Olddog Consulting IETF Internet Draft Old Dog Consulting
Proposed Status: Informational Proposed Status: Informational
Expires: January 2006 Jean-Philippe Vasseur Expires: January 2007 Jean-Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
Arthi Ayyangar Arthi Ayyangar
Juniper Networks Nuova Systems
A Framework for Inter-Domain MPLS Traffic Engineering A Framework for Inter-Domain Multiprotocol Label Switching
Traffic Engineering
draft-ietf-ccamp-inter-domain-framework-04.txt draft-ietf-ccamp-inter-domain-framework-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at line 37 skipping to change at line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
This document provides a framework for establishing and controlling This document provides a framework for establishing and controlling
Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain
networks. networks.
For the purposes of this document, a domain is considered to be any For the purposes of this document, a domain is considered to be any
collection of network elements within a common sphere of address collection of network elements within a common sphere of address
management or path computational responsibility. Examples of such management or path computational responsibility. Examples of such
domains include IGP areas and Autonomous Systems. domains include Interior Gateway Protocol (IGP) areas and Autonomous
Systems (ASs).
Contents Contents
1. Introduction ............................................... 3 1. Introduction ............................................... 3
1.1. Nested Domains ......................................... 3 1.1. Nested Domains ......................................... 3
1.2. Conventions used in this document ...................... 4
2. Signaling Options .......................................... 4 2. Signaling Options .......................................... 4
2.1. LSP Nesting ............................................ 4 2.1. LSP Nesting ............................................ 4
2.2. Contiguous LSP ......................................... 5 2.2. Contiguous LSP ......................................... 5
2.3. LSP Stitching .......................................... 5 2.3. LSP Stitching .......................................... 5
2.4. Hybrid Methods ......................................... 6 2.4. Hybrid Methods ......................................... 6
2.5. Control of Downstream Choice of Signaling Method ....... 6 2.5. Control of Downstream Choice of Signaling Method ....... 6
3. Path Computation Techniques ................................ 6 3. Path Computation Techniques ................................ 6
3.1. Management Configuration ............................... 7 3.1. Management Configuration ............................... 7
3.2. Head End Computation ................................... 7 3.2. Head End Computation ................................... 7
3.2.1. Multi-Domain Visibility Computation ................ 7 3.2.1. Multi-Domain Visibility Computation ................ 7
skipping to change at line 86 skipping to change at line 82
3.5. Optimal Path Computation .............................. 10 3.5. Optimal Path Computation .............................. 10
4. Distributing Reachability and TE Information .............. 11 4. Distributing Reachability and TE Information .............. 11
5. Comments on Advanced Functions ............................ 12 5. Comments on Advanced Functions ............................ 12
5.1. LSP Re-Optimization ................................... 12 5.1. LSP Re-Optimization ................................... 12
5.2. LSP Setup Failure ..................................... 13 5.2. LSP Setup Failure ..................................... 13
5.3. LSP Repair ............................................ 13 5.3. LSP Repair ............................................ 13
5.4. Fast Reroute .......................................... 14 5.4. Fast Reroute .......................................... 14
5.5. Comments on Path Diversity ............................ 15 5.5. Comments on Path Diversity ............................ 15
5.6. Domain-Specific Constraints ........................... 15 5.6. Domain-Specific Constraints ........................... 15
5.7. Policy Control ........................................ 16 5.7. Policy Control ........................................ 16
5.8. Inter-domain OAM ...................................... 16 5.8. Inter-domain Operations and Management (OAM) .......... 16
5.9. Point-to-Multipoint ................................... 16 5.9. Point-to-Multipoint ................................... 16
5.10. Applicability to Non-Packet Technologies ............. 17 5.10. Applicability to Non-Packet Technologies ............. 17
6. Security Considerations ................................... 17 6. Security Considerations ................................... 17
7. IANA Considerations ....................................... 17 7. IANA Considerations ....................................... 18
8. Acknowledgements .......................................... 17 8. Acknowledgements .......................................... 18
9. Intellectual Property Considerations ...................... 17 9. Intellectual Property Considerations ...................... 18
10. Normative References ..................................... 18 10. Normative References ..................................... 19
11. Informational References ................................. 18 11. Informational References ................................. 19
12. Authors' Addresses ....................................... 20 12. Authors' Addresses ....................................... 21
13. Full Copyright Statement ................................. 20 13. Full Copyright Statement ................................. 21
1. Introduction 1. Introduction
The Traffic Engineering Working Group has developed requirements for The Traffic Engineering Working Group has developed requirements for
inter-area and inter-AS MPLS Traffic Engineering in [INTER-AREA] and inter-area and inter-AS Multiprotocol Label Switching (MPLS) Traffic
[INTER-AS]. Engineering in [RFC4105] and [RFC4216].
Various proposals have subsequently been made to address some or all Various proposals have subsequently been made to address some or all
of these requirements through extensions to the RSVP-TE and IGP of these requirements through extensions to the Resource Reservation
(ISIS, OSPF) protocols and procedures. Protocol Traffic Engineering extensions (RSVP-TE) and to the Interior
Gateway Protocols (IGPs) (i.e., ISIS and OSPF).
This document introduces the techniques for establishing Traffic This document introduces the techniques for establishing Traffic
Engineered (TE) Label Switched Paths (LSPs) across multiple domains. Engineered (TE) Label Switched Paths (LSPs) across multiple domains.
In this context and within the remainder of this document, we In this context and within the remainder of this document, we
consider all source-based and constraint-based routed LSPs and refer consider all source-based and constraint-based routed LSPs and refer
to them interchangeably as "TE LSPs" or "LSPs". to them interchangeably as "TE LSPs" or "LSPs".
The functional components of these techniques are separated into the The functional components of these techniques are separated into the
mechanisms for discovering reachability and TE information, for mechanisms for discovering reachability and TE information, for
computing the paths of LSPs, and for signaling the LSPs. Note that computing the paths of LSPs, and for signaling the LSPs. Note that
the aim of this document is not to detail each of those techniques the aim of this document is not to detail each of those techniques
which are covered in separate documents referenced from the sections which are covered in separate documents referenced from the sections
of this document that introduce the techniques, but rather to propose of this document that introduce the techniques, but rather to propose
a framework for inter-domain MPLS Traffic Engineering. a framework for inter-domain MPLS Traffic Engineering.
Note that in the remainder of this document, the term "MPLS Traffic Note that in the remainder of this document, the term "MPLS Traffic
Engineering" is used equally to apply to MPLS and GMPLS traffic. Engineering" is used equally to apply to MPLS and Generalized MPLS
Specific issues pertaining to the use of GMPLS in inter-domain (GMPLS) traffic. Specific issues pertaining to the use of GMPLS in
environments (for example, policy implications of the use of the Link inter-domain environments (for example, policy implications of the
Management Protocol [LMP] on inter-domain links) these are covered in use of the Link Management Protocol [LMP] on inter-domain links)
separate documents such as [GMPLS-AS]. these are covered in separate documents such as [GMPLS-AS].
For the purposes of this document, a domain is considered to be any For the purposes of this document, a domain is considered to be any
collection of network elements within a common sphere of address collection of network elements within a common sphere of address
management or path computational responsibility. Examples of such management or path computational responsibility. Examples of such
domains include IGP areas and Autonomous Systems. Wholly or partially domains include IGP areas and Autonomous Systems. Wholly or partially
overlapping domains (e.g. path computation sub-domains of areas or overlapping domains (e.g. path computation sub-domains of areas or
ASs) are not within the scope of this document. ASs) are not within the scope of this document.
1.1. Nested Domains 1.1. Nested Domains
Nested domains are outside the scope of this document. It may be that Nested domains are outside the scope of this document. It may be that
some domains that are nested administratively or for the purposes of some domains that are nested administratively or for the purposes of
address space management can be considered as adjacent domains for address space management can be considered as adjacent domains for
the purposes of this document, however the fact that the domains are the purposes of this document, however the fact that the domains are
nested is then immaterial. nested is then immaterial. In the context of MPLS TE, domain A is
considered to be nested within domain B if domain A is wholly
In the context of MPLS TE, domain A is considered to be nested within contained in Domain B, and domain B is fully or partially aware of
domain B if domain A is wholly contained in Domain B, and domain B is the TE characteristics and topology of domain A.
fully or partially aware of the TE characteristics and topology of
domain A.
1.2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Signaling Options 2. Signaling Options
Three distinct options for signaling TE LSPs across multiple domains Three distinct options for signaling TE LSPs across multiple domains
are identified. The choice of which options to use may be influenced are identified. The choice of which options to use may be influenced
by the path computation technique used (see section 3), although some by the path computation technique used (see section 3), although some
path computation techniques may apply to multiple signaling options. path computation techniques may apply to multiple signaling options.
The choice may further depend on the application to which the TE LSPs The choice may further depend on the application to which the TE LSPs
are put and the nature, topology and switching capabilities of the are put and the nature, topology and switching capabilities of the
network. network.
A comparison of the usages of the different signaling options is A comparison of the usages of the different signaling options is
beyond the scope of this document and should be the subject of a beyond the scope of this document and should be the subject of a
separate applicability statement. separate applicability statement.
2.1. LSP Nesting 2.1. LSP Nesting
Hierarchical LSPs form a fundamental part of MPLS [RFC3031] and are Hierarchical LSPs form a fundamental part of MPLS [RFC3031] and are
discussed in further detail in [HIER]. Hierarchical LSPs may discussed in further detail in [RFC4206]. Hierarchical LSPs may
optionally be advertised as TE links. Note that a hierarchical LSP optionally be advertised as TE links. Note that a hierarchical LSP
that spans multiple domains cannot be advertised in this way because that spans multiple domains cannot be advertised in this way because
there is no concept of TE information that spans domains. there is no concept of TE information that spans domains.
Hierarchical LSPs can be used in support of inter-domain TE LSPs. Hierarchical LSPs can be used in support of inter-domain TE LSPs.
In particular, a hierarchical LSP may be used to achieve connectivity In particular, a hierarchical LSP may be used to achieve connectivity
between any pair of LSRs within a domain. The ingress and egress of between any pair of Label Switching Routers (LSRs) within a domain.
the hierarchical LSP could be the edge nodes of the domain in which The ingress and egress of the hierarchical LSP could be the edge
case connectivity is achieved across the entire domain, or they could nodes of the domain in which case connectivity is achieved across the
be any other pair of LSRs in the domain. entire domain, or they could be any other pair of LSRs in the domain.
The technique of carrying one TE LSP within another is termed LSP The technique of carrying one TE LSP within another is termed LSP
nesting. A hierarchical LSP may provide a TE LSP tunnel to transport nesting. A hierarchical LSP may provide a TE LSP tunnel to transport
(i.e. nest) multiple TE LSPs along a common part of their paths. (i.e. nest) multiple TE LSPs along a common part of their paths.
Alternatively, a TE LSP may carry (i.e. nest) a single LSP in a Alternatively, a TE LSP may carry (i.e. nest) a single LSP in a
one-to-one mapping. one-to-one mapping.
The signaling trigger for the establishment of a hierarchical LSP may The signaling trigger for the establishment of a hierarchical LSP may
be the receipt of a signaling request for the TE LSP that it will be the receipt of a signaling request for the TE LSP that it will
carry, or may be a management action to "pre-engineer" a domain to be carry, or may be a management action to "pre-engineer" a domain to be
skipping to change at line 208 skipping to change at line 197
according to the properties of the nested LSPs. Even in the dynamic according to the properties of the nested LSPs. Even in the dynamic
case inheritance from the properties of the nested LSP(s) can be case inheritance from the properties of the nested LSP(s) can be
complemented by local or domain-wide policy rules. complemented by local or domain-wide policy rules.
Note that a hierarchical LSP may be constructed to span multiple Note that a hierarchical LSP may be constructed to span multiple
domains or parts of domains. However, such an LSP cannot be domains or parts of domains. However, such an LSP cannot be
advertised as a TE link that spans domains. The end points of a advertised as a TE link that spans domains. The end points of a
hierarchical LSP are not necessarily on domain boundaries, so nesting hierarchical LSP are not necessarily on domain boundaries, so nesting
is not limited to domain boundaries. is not limited to domain boundaries.
Note also that the IGP/EGP routing topology is maintained unaffected Note also that the Interior/Exterior Gateway Protocol (IGP/EGP)
by the LSP connectivity and TE links introduced by hierarchical LSPs routing topology is maintained unaffected by the LSP connectivity and
even if they are advertised as TE links. That is, the routing TE links introduced by hierarchical LSPs even if they are advertised
protocols do not exchange messages over the hierarchical LSPs, and as TE links. That is, the routing protocols do not exchange messages
LSPs are not used to create routing adjacencies between routers. over the hierarchical LSPs, and LSPs are not used to create routing
adjacencies between routers.
During the operation of establishing a nested LSP that uses a During the operation of establishing a nested LSP that uses a
hierarchical LSP, the SENDER_TEMPLATE and SESSION objects remain hierarchical LSP, the SENDER_TEMPLATE and SESSION objects remain
unchanged along the entire length of the nested LSP, as do all other unchanged along the entire length of the nested LSP, as do all other
objects that have end-to-end significance. objects that have end-to-end significance.
2.2. Contiguous LSP 2.2. Contiguous LSP
A single contiguous LSP is established from ingress to egress in a A single contiguous LSP is established from ingress to egress in a
single signaling exchange. No further LSPs are required to be single signaling exchange. No further LSPs are required to be
established to support this LSP so that hierarchical or stitched LSPs established to support this LSP so that hierarchical or stitched LSPs
are not needed. are not needed.
A contiguous LSP uses the same Session/LSP ID along the whole of its A contiguous LSP uses the same Session/LSP ID along the whole of its
path (that is, at each LSR). The notions of "splicing" together path (that is, at each LSR). The notions of "splicing" together
different LSPs, or of "shuffling" Session or LSP identifiers is not different LSPs, or of "shuffling" Session or LSP identifiers is not
considered. considered.
2.3. LSP Stitching 2.3. LSP Stitching
LSP Stitching is described in [STITCH]. LSP Stitching is described in [STITCH]. In the LSP stitching model
separate LSPs (referred to as a TE LSP segments) are established and
In the LSP stitching model separate LSPs (referred to as a TE LSP are "stitched" together in the data plane so that a single end-to-end
segments) are established and are "stitched" together in the data label switched path is achieved. The distinction is that the
plane so that a single end-to-end label switched path is achieved. component LSP segments are signaled as distinct TE LSPs in the
The distinction is that the component LSP segments are signaled as control plane. Each signaled TE LSP segment has a different source
distinct TE LSPs in the control plane. Each signaled TE LSP segment and destination.
has a different source and destination.
LSP stitching can be used in support of inter-domain TE LSPs. In LSP stitching can be used in support of inter-domain TE LSPs. In
particular, an LSP segment may be used to achieve connectivity particular, an LSP segment may be used to achieve connectivity
between any pair of LSRs within a domain. The ingress and egress of between any pair of LSRs within a domain. The ingress and egress of
the LSP segment could be the edge nodes of the domain in which case the LSP segment could be the edge nodes of the domain in which case
connectivity is achieved across the entire domain, or they could be connectivity is achieved across the entire domain, or they could be
any other pair of LSRs in the domain. any other pair of LSRs in the domain.
The signaling trigger for the establishment of a TE LSP segment may The signaling trigger for the establishment of a TE LSP segment may
be the establishment of the previous TE LSP segment, the receipt of be the establishment of the previous TE LSP segment, the receipt of
skipping to change at line 262 skipping to change at line 251
segment, or may be a management action. segment, or may be a management action.
LSP segments may be managed and advertised as TE links. LSP segments may be managed and advertised as TE links.
2.4. Hybrid Methods 2.4. Hybrid Methods
There is nothing to prevent the mixture of signaling methods There is nothing to prevent the mixture of signaling methods
described above when establishing a single, end-to-end, inter-domain described above when establishing a single, end-to-end, inter-domain
TE LSP. It may be desirable in this case for the choice of the TE LSP. It may be desirable in this case for the choice of the
various methods to be reported along the path, perhaps through the various methods to be reported along the path, perhaps through the
RRO. Record Route Object (RRO).
If there is a desire to restrict which methods are used, this MUST be If there is a desire to restrict which methods are used, this must be
signaled as described in the next section. signaled as described in the next section.
2.5. Control of Downstream Choice of Signaling Method 2.5. Control of Downstream Choice of Signaling Method
Notwithstanding the previous section, an ingress LSR MAY wish to Notwithstanding the previous section, an ingress LSR may wish to
restrict the signaling methods applied to a particular LSP at domain restrict the signaling methods applied to a particular LSP at domain
boundaries across the network. Such control, where it is required, boundaries across the network. Such control, where it is required,
may be achieved by the definition of appropriate new flags in the may be achieved by the definition of appropriate new flags in the
SESSION-ATTRIBUTE object or the Attributes Flags TLV of the SESSION-ATTRIBUTE object or the Attributes Flags TLV of the
LSP_ATTRIBUTES object [ATTRIB]. Before defining a mechanism to LSP_ATTRIBUTES object [RFC4420]. Before defining a mechanism to
provide this level of control, the functional requirement to control provide this level of control, the functional requirement to control
the way in which the network delivers a service must be established the way in which the network delivers a service must be established
and due consideration must be given to the impact on and due consideration must be given to the impact on
interoperability since new mechanisms must be backwards compatible, interoperability since new mechanisms must be backwards compatible,
and care must be taken to avoid allowing standards-conformant and care must be taken to avoid allowing standards-conformant
implementations each supporting a different functional subset such implementations each supporting a different functional subset such
that they are not capable of estbalishing LSPs. that they are not capable of establishing LSPs.
3. Path Computation Techniques 3. Path Computation Techniques
The discussion of path computation techniques within this document is The discussion of path computation techniques within this document is
limited significantly to the determination of where computation may limited significantly to the determination of where computation may
take place and what components of the full path may be determined. take place and what components of the full path may be determined.
The techniques used are closely tied to the signaling methodologies The techniques used are closely tied to the signaling methodologies
described in the previous section in that certain computation described in the previous section in that certain computation
techniques may require the use of particular signaling approaches and techniques may require the use of particular signaling approaches and
skipping to change at line 306 skipping to change at line 295
of this document and should be described in a separate applicability of this document and should be described in a separate applicability
statement. statement.
Path computation algorithms are firmly out of scope of this document. Path computation algorithms are firmly out of scope of this document.
3.1. Management Configuration 3.1. Management Configuration
Path computation may be performed by offline tools or by a network Path computation may be performed by offline tools or by a network
planner. The resultant path may be supplied to the ingress LSR as planner. The resultant path may be supplied to the ingress LSR as
part of the TE LSP or service request, and encoded by the ingress LSR part of the TE LSP or service request, and encoded by the ingress LSR
as an ERO on the Path message that is sent out. as an Explicit Route Object (ERO) on the Path message that is sent
out.
There is no reason why the path provided by the operator should not There is no reason why the path provided by the operator should not
span multiple domains if the relevant information is available to the span multiple domains if the relevant information is available to the
planner or the offline tool. The definition of what information is planner or the offline tool. The definition of what information is
needed to perform this operation and how that information is needed to perform this operation and how that information is
gathered, is outside the scope of this document. gathered, is outside the scope of this document.
3.2. Head End Computation 3.2. Head End Computation
The head end, or ingress, LSR may assume responsibility for path The head end, or ingress, LSR may assume responsibility for path
computation when the operator supplies part or none of the explicit computation when the operator supplies part or none of the explicit
path. The operator MUST, in any case, supply at least the destination path. The operator must, in any case, supply at least the destination
address (egress) of the LSP. address (egress) of the LSP.
3.2.1. Multi-Domain Visibility Computation 3.2.1. Multi-Domain Visibility Computation
If the ingress has sufficient visibility of the topology and TE If the ingress has sufficient visibility of the topology and TE
information for all of the domains across which it will route the LSP information for all of the domains across which it will route the LSP
to its destination then it may compute and provide the entire path. to its destination then it may compute and provide the entire path.
The quality of this path (that is, its optimality as discussed in The quality of this path (that is, its optimality as discussed in
section 3.5) can be better if the ingress has full visibility into section 3.5) can be better if the ingress has full visibility into
all relevant domains rather than just sufficient visibility to all relevant domains rather than just sufficient visibility to
skipping to change at line 383 skipping to change at line 373
3.3. Domain Boundary Computation 3.3. Domain Boundary Computation
If the partial explicit path methods described in sections 3.2.2 or If the partial explicit path methods described in sections 3.2.2 or
3.2.3 are applied then the LSR at each domain boundary is responsible 3.2.3 are applied then the LSR at each domain boundary is responsible
for ensuring that there is sufficient path information added to the for ensuring that there is sufficient path information added to the
Path message to carry it at least to the next domain boundary (that Path message to carry it at least to the next domain boundary (that
is, out of the new domain). is, out of the new domain).
If the LSR at the domain boundary has full visibility to the egress If the LSR at the domain boundary has full visibility to the egress
then it can supply the entire explicit path. Note however, that the then it can supply the entire explicit path. Note however, that the
ERO processing rules of [RFC3209] state that it SHOULD only update ERO processing rules of [RFC3209] state that it should only update
the ERO as far as the next specified hop (that is, the next domain the ERO as far as the next specified hop (that is, the next domain
boundary if one was supplied in the original ERO) and, of course, boundary if one was supplied in the original ERO) and, of course,
MUST NOT insert ERO subobjects immediately before a strict hop. must not insert ERO subobjects immediately before a strict hop.
If the LSR at the domain boundary has only partial visibility (using If the LSR at the domain boundary has only partial visibility (using
the definitions of section 3.2.2) it will fill in the path as far as the definitions of section 3.2.2) it will fill in the path as far as
the next domain boundary, and will supply further domain/domain the next domain boundary, and will supply further domain/domain
boundary information if not already present in the ERO. boundary information if not already present in the ERO.
If the LSR at the domain boundary has only local visibility into the If the LSR at the domain boundary has only local visibility into the
immediate domain it will simply add information to the ERO to carry immediate domain it will simply add information to the ERO to carry
the Path message as far as the next domain boundary. the Path message as far as the next domain boundary.
Domain boundary path computations are performed independently from Domain boundary path computations are performed independently from
each other. Domain boundary LSRs may have different computation each other. Domain boundary LSRs may have different computation
capabilities, run different path computation algorithms, apply capabilities, run different path computation algorithms, apply
different sets of constraints and optimization criteria, and so different sets of constraints and optimization criteria, and so
forth, which might result in path segment quality which is forth, which might result in path segment quality which is
unpredictable to and out of the control of the ingress LSR. A unpredictable to and out of the control of the ingress LSR. A
solution to this issue lies in enhancing the informaiton signaled solution to this issue lies in enhancing the information signaled
during LSP setup to include a larger set of constraints and to during LSP setup to include a larger set of constraints and to
include the paths of related LSPs (such as diverse protected LSPs) include the paths of related LSPs (such as diverse protected LSPs)
as described in [GMPLS-E2E]. as described in [GMPLS-E2E].
It is also the case that paths generated on domain boundaries may It is also the case that paths generated on domain boundaries may
produce loops. Specifically, the paths computed may loop back into a produce loops. Specifically, the paths computed may loop back into a
domain that has already been crossed by the LSP. This may, or may not domain that has already been crossed by the LSP. This may, or may not
be a problem, and might even be desirable, but could also give rise be a problem, and might even be desirable, but could also give rise
to real loops. This can be avoided by using the recorded route (RRO) to real loops. This can be avoided by using the recorded route (RRO)
to provide exclusions within the path computation algorithm, but in to provide exclusions within the path computation algorithm, but in
skipping to change at line 454 skipping to change at line 444
3.4.1. Multi-Domain Visibility Computation 3.4.1. Multi-Domain Visibility Computation
A PCE may have full visibility, perhaps through connectivity to A PCE may have full visibility, perhaps through connectivity to
multiple domains. In this case it is able to supply a full explicit multiple domains. In this case it is able to supply a full explicit
path as in section 3.2.1. path as in section 3.2.1.
3.4.2. Path Computation Use of PCE When Preserving Confidentiality 3.4.2. Path Computation Use of PCE When Preserving Confidentiality
Note that although a centralized PCE or multiple collaborative PCEs Note that although a centralized PCE or multiple collaborative PCEs
may have full visibility into one or more domains, it may be may have full visibility into one or more domains, it may be
desirable (e.g to preserve confidentiality) that the full path is not desirable (e.g. to preserve topology confidentiality) that the full
provided to the ingress LSR. Instead, a partial path is supplied (as path is not provided to the ingress LSR. Instead, a partial path is
in section 3.2.2 or 3.2.3) and the LSRs at each domain boundary are supplied (as in section 3.2.2 or 3.2.3) and the LSRs at each domain
required to make further requests for each successive segment of the boundary are required to make further requests for each successive
path. segment of the path.
In this way an end-to-end path may be computed using the full network In this way an end-to-end path may be computed using the full network
capabilities, but confidentiality between domains may be preserved. capabilities, but confidentiality between domains may be preserved.
Optionally, the PCE(s) may compute the entire path at the first Optionally, the PCE(s) may compute the entire path at the first
request and hold it in storage for subsequent requests, or it may request and hold it in storage for subsequent requests, or it may
recompute each leg of the path on each request or at regular recompute each leg of the path on each request or at regular
intervals until requested by the LSRs establishing the LSP. intervals until requested by the LSRs establishing the LSP.
It may be the case that the centralized PCE or the collaboration It may be the case that the centralized PCE or the collaboration
between PCEs may define a trust relationship greater than that between PCEs may define a trust relationship greater than that
skipping to change at line 521 skipping to change at line 511
The path computation techniques described in the previous section The path computation techniques described in the previous section
make certain demands upon the distribution of reachability make certain demands upon the distribution of reachability
information and the TE capabilities of nodes and links within domains information and the TE capabilities of nodes and links within domains
as well as the TE connectivity across domains. as well as the TE connectivity across domains.
Currently, TE information is distributed within domains by additions Currently, TE information is distributed within domains by additions
to IGPs [RFC3630], [RFC3784]. to IGPs [RFC3630], [RFC3784].
In cases where two domains are interconnected by one or more links In cases where two domains are interconnected by one or more links
(that is, the domain boundary falls on a link rather than on a node), (that is, the domain boundary falls on a link rather than on a node),
there SHOULD be a mechanism to distribute the TE information there should be a mechanism to distribute the TE information
associated with the inter-domain links to the corresponding domains. associated with the inter-domain links to the corresponding domains.
This would facilitate better path computation and reduce TE-related This would facilitate better path computation and reduce TE-related
crankbacks on these links. crankbacks on these links.
Where a domain is a subset of an IGP area, filtering of TE Where a domain is a subset of an IGP area, filtering of TE
information may be applied at the domain boundary. This filtering may information may be applied at the domain boundary. This filtering may
be one way, or two way. be one way, or two way.
Where information needs to reach a PCE that spans multiple domains, Where information needs to reach a PCE that spans multiple domains,
the PCE may snoop on the IGP traffic in each domain, or play an the PCE may snoop on the IGP traffic in each domain, or play an
active part as an IGP-capable node in each domain. The PCE might also active part as an IGP-capable node in each domain. The PCE might also
receive TED updates from a proxy within the domain. receive TED updates from a proxy within the domain.
It could be possible that an LSR that performs path computation (for It could be possible that an LSR that performs path computation (for
example, an ingress LSR) obtains the topology and TE information of example, an ingress LSR) obtains the topology and TE information of
not just its own domain, but other domains as well. This information not just its own domain, but other domains as well. This information
may be subject to filtering applied by the advertising domain (for may be subject to filtering applied by the advertising domain (for
example, the information may be limited to FAs across other domains, example, the information may be limited to Forwarding Adjacencies
or the information may be aggregated or abstracted). (FAs) across other domains, or the information may be aggregated or
abstracted).
Before starting work on any protocols or protocol extensions to Before starting work on any protocols or protocol extensions to
enable cross-domain reachability and TE advertisement in support of enable cross-domain reachability and TE advertisement in support of
inter-domain TE, the requirements and and benefits must be clearly inter-domain TE, the requirements and benefits must be clearly
established. This has not been done to date. Where any cross-domain established. This has not been done to date. Where any cross-domain
reachability and TE information needs to be advertised, consideration reachability and TE information needs to be advertised, consideration
must be given to TE extensions to existing protocols such as BGP, and must be given to TE extensions to existing protocols such as BGP, and
how the information advertised may be fed to the IGPs. It must be how the information advertised may be fed to the IGPs. It must be
noted that any extensions that cause a significant increase in the noted that any extensions that cause a significant increase in the
amount of processing (such as aggregation computation) at domain amount of processing (such as aggregation computation) at domain
boundaries, or a significant increase in the amount of information boundaries, or a significant increase in the amount of information
flooded (such as detailed TE information) need to be treated with flooded (such as detailed TE information) need to be treated with
extreme caution and compared carefully with the scaling requirements extreme caution and compared carefully with the scaling requirements
expressed in [INTER-AREA] and [INTER-AS]. expressed in [RFC4105] and [RFC4216].
5. Comments on Advanced Functions 5. Comments on Advanced Functions
This section provides some non-definitive comments on the constraints This section provides some non-definitive comments on the constraints
placed on advanced MPLS TE functions by inter-domain MPLS. It does placed on advanced MPLS TE functions by inter-domain MPLS. It does
not attempt to state the implications of using one inter-domain not attempt to state the implications of using one inter-domain
technique or another. Such material is deferred to appropriate technique or another. Such material is deferred to appropriate
applicability statements where statements about the capabilities of applicability statements where statements about the capabilities of
existing or future signaling, routing and computation techniques to existing or future signaling, routing and computation techniques to
deliver the functions listed should be made. deliver the functions listed should be made.
skipping to change at line 589 skipping to change at line 580
domains. domains.
Re-optimization requires that all or part of the path of the LSP be Re-optimization requires that all or part of the path of the LSP be
re-computed. The techniques used may be selected as described in re-computed. The techniques used may be selected as described in
section 3, and this will influence whether the whole or part of the section 3, and this will influence whether the whole or part of the
path is re-optimized. path is re-optimized.
The trigger for path computation and re-optimization may be an The trigger for path computation and re-optimization may be an
operator request, a timer, information about a change in operator request, a timer, information about a change in
availability of network resources, or a change in operational availability of network resources, or a change in operational
parameters (for example bandwidth) of an LSP. This trigger MUST be parameters (for example bandwidth) of an LSP. This trigger must be
applied to the point in the network that requests re-computation and applied to the point in the network that requests re-computation and
controls re-optimization and may require additional signaling. controls re-optimization and may require additional signaling.
Note also that where multiple mutually-diverse paths are applied Note also that where multiple mutually-diverse paths are applied
end-to-end (i.e. not simply within protection domains - see section end-to-end (i.e. not simply within protection domains - see section
5.5) the point of calculation for re-optimization (whether it is PCE, 5.5) the point of calculation for re-optimization (whether it is PCE,
ingress, or domain entry point) needs to know all such paths before ingress, or domain entry point) needs to know all such paths before
attempting re-optimization of any one path. Mutual diversity here attempting re-optimization of any one path. Mutual diversity here
means that a set of computed paths have no commonality. Such means that a set of computed paths have no commonality. Such
diversity might be link, node, SRLG or even domain disjointedness diversity might be link, node, Shared Risk Link Group (SRLG) or even
according to circumstances and the service being delivered. domain disjointedness according to circumstances and the service
being delivered.
It may be the case that re-optimization is best achieved by It may be the case that re-optimization is best achieved by
recomputing the paths of multiple LSPs at once. Indeed, this can be recomputing the paths of multiple LSPs at once. Indeed, this can be
shown to be most efficient when the paths of all LSPs are known, not shown to be most efficient when the paths of all LSPs are known, not
simply those LSPs that originate at a particular ingress. While this simply those LSPs that originate at a particular ingress. While this
problem is inherited from single domain re-optimization and is out of problem is inherited from single domain re-optimization and is out of
scope within this document, it should be noted that the problem grows scope within this document, it should be noted that the problem grows
in complexity when LSPs wholly within one domain affect the in complexity when LSPs wholly within one domain affect the
re-optimization path calculations performed in another domain. re-optimization path calculations performed in another domain.
skipping to change at line 625 skipping to change at line 617
LSP. LSP.
In the first instance, a retry may be attempted within the domain In the first instance, a retry may be attempted within the domain
that contains the failure. That retry may be attempted by nodes that contains the failure. That retry may be attempted by nodes
wholly within the domain, or the failure may be referred back to the wholly within the domain, or the failure may be referred back to the
LSR at the domain boundary. LSR at the domain boundary.
If the failure cannot be bypassed within the domain where the failure If the failure cannot be bypassed within the domain where the failure
occurred (perhaps there is no suitable alternate route, perhaps occurred (perhaps there is no suitable alternate route, perhaps
rerouting is not allowed by domain policy, or perhaps the Path rerouting is not allowed by domain policy, or perhaps the Path
message specifically bans such action), the error MUST be reported message specifically bans such action), the error must be reported
back to the previous or head-end domain. back to the previous or head-end domain.
Subsequent repair attempts may be made by domains further upstream, Subsequent repair attempts may be made by domains further upstream,
but will only be properly effective if sufficient information about but will only be properly effective if sufficient information about
the failure and other failed repair attempts is also passed back the failure and other failed repair attempts is also passed back
upstream [CRANKBACK]. Note that there is a tension between this upstream [CRANKBACK]. Note that there is a tension between this
requirement and that of confidentiality although crankback requirement and that of topology confidentiality although crankback
aggregation may be applicable at domain boundaries. aggregation may be applicable at domain boundaries.
Further attempts to signal the failed LSP may apply the information Further attempts to signal the failed LSP may apply the information
about the failures as constraints to path computation, or may signal about the failures as constraints to path computation, or may signal
them as specific path exclusions [EXCLUDE]. them as specific path exclusions [EXCLUDE].
When requested by signaling, the failure may also be systematically When requested by signaling, the failure may also be systematically
reported to the head-end LSR. reported to the head-end LSR.
5.3. LSP Repair 5.3. LSP Repair
An LSP that fails after it has been established may be repaired An LSP that fails after it has been established may be repaired
dynamically by re-routing. The behavior in this case is either like dynamically by re-routing. The behavior in this case is either like
that for re-optimization, or for handling setup failures (see that for re-optimization, or for handling setup failures (see
previous two sections). previous two sections). Fast Reroute may also be used (see below).
Fast Reroute may also be used (see below).
5.4. Fast Reroute 5.4. Fast Reroute
MPLS Traffic Engineering Fast Reroute ([FRR]) defines local MPLS Traffic Engineering Fast Reroute ([RFC4090]) defines local
protection schemes intended to provide fast recovery (in 10s of protection schemes intended to provide fast recovery (in 10s of
msecs) of fast-reroutable packet-based TE LSPs upon link/SRLG/Node msecs) of fast-reroutable packet-based TE LSPs upon link/SRLG/Node
failure. A backup TE LSP is configured and signaled at each hop, and failure. A backup TE LSP is configured and signaled at each hop, and
activated upon detecting or being informed of a network element activated upon detecting or being informed of a network element
failure. The node immediately upstream of the failure (called the PLR failure. The node immediately upstream of the failure (called the PLR
- Point of Local Repair) reroutes the set of protected TE LSPs onto - Point of Local Repair) reroutes the set of protected TE LSPs onto
the appropriate backup tunnel(s) and around the failed resource. the appropriate backup tunnel(s) and around the failed resource.
In the context of inter-domain TE, there are several different In the context of inter-domain TE, there are several different
failure scenarios that must be analyzed. Provision of suitable failure scenarios that must be analyzed. Provision of suitable
solutions may be further complicated by the fact that [FRR] specifies solutions may be further complicated by the fact that [RFC4090]
two distinct modes of operation referred to as the "one to one mode" specifies two distinct modes of operation referred to as the "one to
and the "facility back-up mode". one mode" and the "facility back-up mode".
The failure scenarios specific to inter-domain TE are as follows: The failure scenarios specific to inter-domain TE are as follows:
- Failure of a domain edge node that is present in both domains. - Failure of a domain edge node that is present in both domains.
There are two sub-cases: There are two sub-cases:
- The PLR and the MP are in the same domain - The Point of Local Repair (PLR) and the Merge Point (MP) are in
the same domain
- The PLR and the MP are in different domains. - The PLR and the MP are in different domains.
- Failure of a domain edge node that is only present in one of the - Failure of a domain edge node that is only present in one of the
domains. domains.
- Failure of an inter-domain link. - Failure of an inter-domain link.
Although it may be possible to apply the same techniques for FRR to Although it may be possible to apply the same techniques for FRR to
the different methods of signaling inter-domain LSPs described in the different methods of signaling inter-domain LSPs described in
section 2, the results of protection may be different when it is the section 2, the results of protection may be different when it is the
boundary nodes that need to be protected, and when they are the boundary nodes that need to be protected, and when they are the
ingress and egress of a hierarchical LSP or stitched LSP segment. In ingress and egress of a hierarchical LSP or stitched LSP segment. In
particular, the choice of Point of Local Repair (PLR) and Merge Point particular, the choice of PLR and MP may be different, and the length
(MP) may be different, and the length of the protection path may be of the protection path may be greater. These use of FRR techniques
greater. These use of FRR techniques should be explained further in should be explained further in applicability statements or, in the
applicability statements or, in the case of a change in base case of a change in base behavior, in implementation guidelines
behavior, in implementation guidelines specific to the signaling specific to the signaling techniques.
techniques.
Note that after local repair has been performed, it may be desirable Note that after local repair has been performed, it may be desirable
to re-optimize the LSP (see section 5.1). If the point of to re-optimize the LSP (see section 5.1). If the point of
re-optimization (for example the ingress LSR) lies in a different re-optimization (for example the ingress LSR) lies in a different
domain to the failure, it may rely on the delivery of a PathErr or domain to the failure, it may rely on the delivery of a PathErr or
Notify message to inform it of the local repair event. Notify message to inform it of the local repair event.
It is important to note that Fast Reroute techniques are only It is important to note that Fast Reroute techniques are only
applicable to packet switching networks because other network applicable to packet switching networks because other network
technologies cannot apply label stacking within the same switching technologies cannot apply label stacking within the same switching
skipping to change at line 732 skipping to change at line 722
domains. domains.
Many network technologies utilize "protection domains" because they Many network technologies utilize "protection domains" because they
fit well with the capabilities of the technology. As a result, many fit well with the capabilities of the technology. As a result, many
domains are operated as protection domains. In this model, protection domains are operated as protection domains. In this model, protection
paths converge at domain boundaries. paths converge at domain boundaries.
Note that the question of SRLG identification is not yet fully Note that the question of SRLG identification is not yet fully
answered. There are two classes of SRLG: answered. There are two classes of SRLG:
- those that indicate resources that are all contained witin one - those that indicate resources that are all contained within one
domain domain
- those that span domains. - those that span domains.
The former might be identified using a combination of a globally The former might be identified using a combination of a globally
scoped domain ID, and an SRLG ID that is administered by the domain. scoped domain ID, and an SRLG ID that is administered by the domain.
The latter requires a global scope to the SRLG ID. Both schemes, The latter requires a global scope to the SRLG ID. Both schemes,
therefore, require external administration. The former is able to therefore, require external administration. The former is able to
leverage existing domain ID administration (for example, area and AS leverage existing domain ID administration (for example, area and AS
numbers), but the latter would require a new administrative policy. numbers), but the latter would require a new administrative policy.
skipping to change at line 759 skipping to change at line 749
different meanings in different domains and this may impact the different meanings in different domains and this may impact the
ability to support DiffServ-aware MPLS, or to manage pre-emption. ability to support DiffServ-aware MPLS, or to manage pre-emption.
In order to achieve consistent meaning and LSP establishment, this In order to achieve consistent meaning and LSP establishment, this
fact must be considered when performing constraint-based path fact must be considered when performing constraint-based path
computation or when signaling across domain boundaries. computation or when signaling across domain boundaries.
A mapping function can be derived for most constraints based on A mapping function can be derived for most constraints based on
policy agreements between the Domain administrators. The details of policy agreements between the Domain administrators. The details of
such a mapping function are outside the scope of this document, but such a mapping function are outside the scope of this document, but
it is important to note that the default behavior MUST either be it is important to note that the default behavior must either be
that a constant mapping is applied or that any requirement to apply that a constant mapping is applied or that any requirement to apply
these constraints across a domain boundary must fail in the absence these constraints across a domain boundary must fail in the absence
of explicit mapping rules. of explicit mapping rules.
5.7. Policy Control 5.7. Policy Control
Domain boundaries are natural points for policy control. There is Domain boundaries are natural points for policy control. There is
little to add on this subject except to note that a TE LSP that little to add on this subject except to note that a TE LSP that
cannot be established on a path through one domain because of a cannot be established on a path through one domain because of a
policy applied at the domain boundary, may be satisfactorily policy applied at the domain boundary, may be satisfactorily
established using a path that avoids the demurring domain. In any established using a path that avoids the demurring domain. In any
case, when a TE LSP signaling attempt is rejected due to case, when a TE LSP signaling attempt is rejected due to
non-compliance with some policy constraint, this SHOULD be reflected non-compliance with some policy constraint, this should be reflected
to the ingress LSR. to the ingress LSR.
5.8. Inter-domain OAM 5.8. Inter-domain Operations and Management (OAM)
Some elements of OAM may be intentionally confined within a domain. Some elements of OAM may be intentionally confined within a domain.
Others (such as end-to-end liveness and connectivity testing) clearly Others (such as end-to-end liveness and connectivity testing) clearly
need to span the entire multi-domain TE LSP. Where issues of need to span the entire multi-domain TE LSP. Where issues of
confidentiality are strong, collaboration between PCEs or domain topology confidentiality are strong, collaboration between PCEs or
boundary nodes might be required in order to provide end-to-end OAM, domain boundary nodes might be required in order to provide
and a significant issue to be resolved is to ensure that the end-to-end OAM, and a significant issue to be resolved is to ensure
end-points support the various OAM capabilities. that the end-points support the various OAM capabilities.
The different signaling mechanisms described above may need The different signaling mechanisms described above may need
refinements to [LSPPING], and [BFD-MPLS], etc., to gain full refinements to [RFC4379], and [BFD-MPLS], etc., to gain full
end-to-end visibility. These protocols should, however, be considered end-to-end visibility. These protocols should, however, be considered
in the light of confidentiality requirements. in the light of topology confidentiality requirements.
Route recording is a commonly used feature of signaling that provides Route recording is a commonly used feature of signaling that provides
OAM information about the path of an established LSP. When an LSP OAM information about the path of an established LSP. When an LSP
traverses a domain boundary, the border node may remove or aggregate traverses a domain boundary, the border node may remove or aggregate
some of the recorded information for confidentiality or other policy some of the recorded information for topology confidentiality or
reasons. other policy reasons.
5.9. Point-to-Multipoint 5.9. Point-to-Multipoint
Inter-domain point-to-multipoint (P2MP) requirements are explicitly Inter-domain point-to-multipoint (P2MP) requirements are explicitly
out of scope of this document. They may be covered by other documents out of scope of this document. They may be covered by other documents
dependent on the details of MPLS TE P2MP solutions. dependent on the details of MPLS TE P2MP solutions.
5.10. Applicability to Non-Packet Technologies 5.10. Applicability to Non-Packet Technologies
Non-packet switching technologies may present particular issues for Non-packet switching technologies may present particular issues for
skipping to change at line 821 skipping to change at line 811
segment protection [GMPLS-SEG] that is applicable to both packet and segment protection [GMPLS-SEG] that is applicable to both packet and
non-packet switching technologies. non-packet switching technologies.
The specific architectural considerations and requirements for The specific architectural considerations and requirements for
inter-domain LSP setup in non-packet networks are covered in a inter-domain LSP setup in non-packet networks are covered in a
separate document [GMPLS-AS]. separate document [GMPLS-AS].
6. Security Considerations 6. Security Considerations
Requirements for security within domains are unchanged from [RFC3209] Requirements for security within domains are unchanged from [RFC3209]
and [RFC3473], but requirements for inter-domain security are, if and [RFC3473], and from [RFC3630] and [RFC3784]. That is, all
anything, more significant. security procedures for existing protocols in the MPLS context
continue to apply for the intra-domain cases.
Authentication techniques identified for use with RSVP-TE can only Inter-domain security may be considered as a more important and more
operate across domain boundaries if there is coordination between the sensitive issue than intra-domain security since in inter-domain
administrators of those domains. traffic engineering control and information may be passed across
administrative boundaries. The most obvious, and most sensitive case
is inter-AS TE.
Confidentiality may also be considered to be security factors. All of the intra-domain security measures for the signaling and
routing protocols are equally applicable and efficacious in the
inter-domain case, and it may be reasonably assumed that if the
measures are strong enough for intra-domain security then they are
also strong enough for inter-domain security. There is, however, a
greater likelihood of them being applied in the inter-domain case.
Similarly, the PCE procedures [PCE] are subject to security measures
for the exchange computation information between PCEs, and for LSRs
that request path computations from a PCE. The requirements for this
security (set out in [PCE-REQ]) apply whether the LSR and PCE (or the
cooperating PCEs) are in the same domain or lie across domain
boundaries.
It should be noted, however, that techniques used for (for example)
authentication require coordination of secrets, keys, or passwords
between sender and receiver. Where sender and receiver lie within a
single administrative domain, this process may be simple. But where
sender and receiver lie in different administrative domains,
cross-domain coordination between network administrators will be
required in order to provide adequate security. At this stage, it is
not proposed that this coordination be provided through an automatic
process nor through the use of a protocol. Human-to-human
coordination is more likely to provide the required level of
confidence in the inter-domain security.
One new security concept is introduced by inter-domain MPLS TE. This
is the preservation of confidentiality of topology information. That
is, one domain may wish to keep secret the way that its network is
constructed and the availability (or otherwise) of end-to-end network
resources. This issue is discussed in sections 3.4.2, 5.2, and 5.8 of
this document. When there is a requirement to preserve inter-domain
topology confidentiality, policy filters must be applied at the
domain boundaries to avoid distributing such information. This is the
responsibility of the domain that distributes information, and may be
adequately addressed by aggregation of information as described in
the referenced sections.
Applicability statements for particular combinations of signaling, Applicability statements for particular combinations of signaling,
routing and path computation techniques are expected to contain routing, and path computation techniques to provide inter-domain MPLS
detailed security sections. TE solutions are expected to contain detailed security sections.
7. IANA Considerations 7. IANA Considerations
This document makes no requests for any IANA action. This document makes no requests for any IANA action.
8. Acknowledgements 8. Acknowledgements
The authors would like to extend their warmest thanks to Kireeti The authors would like to extend their warmest thanks to Kireeti
Kompella for convincing them to expend effort on this document. Kompella for convincing them to expend effort on this document.
Grateful thanks to Dimitri Papadimitriou, Tomohiro Otani and Igor Grateful thanks to Dimitri Papadimitriou, Tomohiro Otani and Igor
Bryskin for their review and suggestions on the text. Bryskin for their review and suggestions on the text.
Thanks to Jari Arkko, Gonzalo Camarillo, Brian Carpenter,
Lisa Dusseault, Sam Hartman, Russ Housley, and Dan Romascanu for
final review of the text.
9. Intellectual Property Considerations 9. Intellectual Property Considerations
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.
skipping to change at line 872 skipping to change at line 905
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 this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
10. Normative References 10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, [RFC3031] Rosen, E., Viswanathan, A. and R. Callon,
"Multiprotocol Label Switching Architecture", RFC 3031, "Multiprotocol Label Switching Architecture", RFC 3031,
January 2001. January 2001.
[RFC3209] Awduche, et al, "Extensions to RSVP for LSP Tunnels", [RFC3209] Awduche, et al, "Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001. RFC 3209, December 2001.
[RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label [RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation Switching (GMPLS) Signaling - Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003. RFC 3473, January 2003.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004. RFC 3667, February 2004.
[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004. Technology", BCP 79, RFC 3668, February 2004.
11. Informational References
[RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF Version 2", RFC 3630, September 2003 Extensions to OSPF Version 2", RFC 3630, September 2003
[RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic
Engineering", RFC 3784, June 2004. Engineering", RFC 3784, June 2004.
[ATTRIB] A. Farrel, D. Papadimitriou, JP. Vasseur, "Encoding of 11. Informational References
[RFC4420] A. Farrel, D. Papadimitriou, JP. Vasseur, "Encoding of
Attributes for Multiprotocol Label Switching (MPLS) Attributes for Multiprotocol Label Switching (MPLS)
Label Switched Path (LSP) Establishment Using RSVP-TE", Label Switched Path (LSP) Establishment Using RSVP-TE",
draft-ietf-mpls-rsvpte-attributes, work in progress. RFC 4420, February 2006.
[BFD-MPLS] R. Aggarwal and K. Kompella, "BFD For MPLS LSPs", work [BFD-MPLS] R. Aggarwal and K. Kompella, "BFD For MPLS LSPs", work
in progress. in progress.
[CRANKBACK] Farrel, A., et al., "Crankback Signaling Extensions for [CRANKBACK] Farrel, A., et al., "Crankback Signaling Extensions for
MPLS Signaling", draft-ietf-ccamp-crankback, MPLS Signaling", draft-ietf-ccamp-crankback,
work in progress. work in progress.
[EXCLUDE] Lee et all, Exclude Routes - Extension to RSVP-TE, [EXCLUDE] Lee et all, Exclude Routes - Extension to RSVP-TE,
draft-ietf-ccamp-rsvp-te-exclude-route, work in draft-ietf-ccamp-rsvp-te-exclude-route, work in
progress. progress.
[FRR] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE [RFC4090] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE
for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute, for LSP Tunnels", RFC 4090, May 2005.
work in progress.
[GMPLS-AS] Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS [GMPLS-AS] Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS
Traffic Engineering Requirements", Traffic Engineering Requirements",
draft-otani-ccamp-interas-GMPLS-TE, work in progress. draft-otani-ccamp-interas-GMPLS-TE, work in progress.
[GMPLS-E2E] Lang, J.P., Rekhter, Y., Papadimitriou, D., Editors, [GMPLS-E2E] Lang, J.P., Rekhter, Y., Papadimitriou, D., Editors,
"RSVP-TE Extensions in support of End-to-End "RSVP-TE Extensions in support of End-to-End
GMPLS-based Recovery", GMPLS-based Recovery",
draft-lang-ccamp-gmpls-recovery-e2e-signaling, work in draft-lang-ccamp-gmpls-recovery-e2e-signaling, work in
progress. progress.
[HIER] Kompella K., Rekhter Y., "LSP Hierarchy with [RFC4206] Kompella K., Rekhter Y., "LSP Hierarchy with
Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy, Generalized MPLS TE", RFC 4206, October 2005.
work in progress.
[INTER-AREA] Le Roux, Vasseur et Boyle, "Requirements for support of
Inter-Area and Inter-AS MPLS Traffic Engineering",
draft-ietf-tewg-interarea-mpls-te-req, work in
progress.
[INTER-AS] Zhang, R., Vasseur, JP. et al, "MPLS Inter-AS Traffic [RFC4105] Le Roux, Vasseur et Boyle, "Requirements for Inter-Area
Engineering requirements", MPLS Traffic Engineering", RFC 4105, June 2005.
draft-ietf-tewg-interas-mpls-te-req, work in progress.
[LSPPING] Kompella, K., et al., " Detecting Data Plane Liveliness [RFC4216] Zhang, R., Vasseur, JP. et al, "MPLS Inter-Autonomous
in MPLS", draft-ietf-mpls-lsp-ping, work in progress. System (AS) Traffic Engineering (TE) Requirements",
RFC 4216, November 2005.
[OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay [RFC4379] Kompella, K., and Swallow, G., "Detecting Multi-
Model", draft-ietf-ccamp-gmpls-overlay, work in Protocol Label Switched (MPLS) Data Plane Failures",
progress. RFC 4379, February 2006.
[PCE] Ash, G., Farrel, A., and Vasseur, JP., "Path [PCE] Ash, G., Farrel, A., and Vasseur, JP., "Path
Computation Element (PCE) Architecture", Computation Element (PCE) Architecture",
draft-ietf-pce-architecture, work in progress. draft-ietf-pce-architecture, work in progress.
[PCE-REQ] Ash, G., and Le Roux, J.L., "PCE Communication Protocol
Generic Requirements",
draft-ietf-pce-comm-protocol-gen-reqs, work in
progress.
[SEG-PROT] Berger, L., Bryskin, I., Papadimitriou, D. and Farrel, [SEG-PROT] Berger, L., Bryskin, I., Papadimitriou, D. and Farrel,
A., "GMPLS Based Segment Recovery", A., "GMPLS Based Segment Recovery",
draft-ietf-ccamp-gmpls-segment-recovery, work in draft-ietf-ccamp-gmpls-segment-recovery, work in
progress. progress.
[STITCH] Ayyangar, A., and Vasseur, JP., "LSP Stitching with [STITCH] Ayyangar, A., and Vasseur, JP., "LSP Stitching with
Generalized MPLS TE", Generalized MPLS TE",
draft-ietf-ccamp-lsp-stitching, work in progress. draft-ietf-ccamp-lsp-stitching, work in progress.
12. Authors' Addresses 12. Authors' Addresses
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Jean-Philippe Vasseur JP Vasseur
Cisco Systems, Inc. Cisco Systems, Inc
300 Beaver Brook Road 1414 Massachusetts Avenue
Boxborough , MA - 01719 Boxborough, MA 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
Arthi Ayyangar Arthi Ayyangar
Juniper Networks, Inc Nuova Systems
1194 N.Mathilda Ave Email: arthi@nuovasystems.com
Sunnyvale, CA 94089
USA
Email: arthi@juniper.net
13. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 68 change blocks. 
154 lines changed or deleted 179 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/