draft-ietf-ccamp-inter-domain-framework-00.txt   draft-ietf-ccamp-inter-domain-framework-01.txt 
Network Working Group Adrian Farrel Network Working Group Adrian Farrel
IETF Internet Draft Olddog Consulting IETF Internet Draft Olddog Consulting
Proposed Status: Informational Proposed Status: Informational
Expires: January 2004 Jean-Philippe Vasseur Expires: August 2005 Jean-Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
Arthi Ayyangar Arthi Ayyangar
Juniper Networks Juniper Networks
August 2004 February 2005
draft-ietf-ccamp-inter-domain-framework-00.txt
A Framework for Inter-Domain MPLS Traffic Engineering A Framework for Inter-Domain MPLS Traffic Engineering
draft-ietf-ccamp-inter-domain-framework-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of Section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with 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 become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Working documents of the Internet Engineering Task Force (IETF), its Internet-Drafts are working documents of the Internet Engineering
areas, and its working groups. Note that other groups may also Task Force (IETF), its areas, and its working groups. Note that
distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. 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)
Label Switched Paths (LSPs) in multi-domain networks. Label Switched Paths (LSPs) in multi-domain 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 IGP areas and Autonomous Systems.
Contents
1. Introduction ...............................................
1.1. Nested Domains .........................................
1.2. Conventions used in this document ......................
2. Signaling Options ..........................................
2.1. LSP Nesting ............................................
2.2. Contiguous LSP .........................................
2.3. LSP Stitching ..........................................
2.4. Hybrid Methods .........................................
2.5. Control of Downstream Choice of Signaling Method ....... x
3. Path Computation Techniques ................................
3.1. Management Configuration ...............................
3.2. Head End Computation ...................................
3.2.1. Multi-Domain Visibility Computation ................
3.2.2. Partial Visibility Computation .....................
3.2.3. Local Domain Visibility Computation ................
3.3. Domain Boundary Computation ............................
3.4. Path Computation Element ...............................
3.4.1. Multi-Domain Visibility Computation ................
3.4.2. Path Computation Use of PCE When Preserving
Confidentiality ....................................
3.4.3. Per-Domain Computation Servers .....................
3.5. Optimal Path Computation ...............................
4. Distributing Reachability and TE Information ...............
5. Comments on Advanced Functions .............................
5.1. LSP Re-Optimization ....................................
5.2. LSP Setup Failure ......................................
5.3. LSP Repair .............................................
5.4. Fast Reroute ...........................................
5.5. Comments on Path Diversity .............................
5.6. Domain-Specific Constraints ............................
5.7. Policy Control .........................................
5.8. Inter-domain OAM .......................................
5.9. Point-to-Multipoint ....................................
5.10. Applicability to Non-Packet Technologies ..............
6. Security Considerations ....................................
7. IANA Considerations ........................................
8. Acknowledgements ...........................................
9. Intellectual Property Considerations .......................
10. Normative References ......................................
11. Informational References ..................................
12. Authors' Addresses ........................................
13. Full Copyright Statement ..................................
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 MPLS Traffic Engineering in [INTER-AREA] and
[INTER-AS]. [INTER-AS].
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 RSVP-TE and IGP
(ISIS, OSPF) protocols and procedures. (ISIS, OSPF) protocols and procedures.
This document introduces the techniques for establishing TE LSPs This document introduces the techniques for establishing TE LSPs
across multiple domains. The functional components of these across multiple domains. The functional components of these
techniques are separated into the mechanisms for discovering techniques are separated into the mechanisms for discovering
reachability and TE information, for computing the paths of LSPs, and reachability and TE information, for computing the paths of LSPs, and
for signaling the LSPs. Note that the aim is this document is not to for signaling the LSPs. Note that the aim of this document is not to
detail each of those techniques which are covered in separate detail each of those techniques which are covered in separate
documents, but rather to propose a framework for inter-domain MPLS documents, but rather to propose a framework for inter-domain MPLS
Traffic Engineering. Traffic Engineering.
Note that in the remainder of this document, the term 'MPLS Traffic
Engineering' is used equally to apply to MPLS and GMPLS traffic
engineering in packet and non-packet environments.
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. However, domains of domains include IGP areas and Autonomous Systems. However, domains of
computational responsibility may also exist as sub-domains of areas computational responsibility may also exist as sub-domains of areas
or ASs. Wholly or partially overlapping domains are not within the or ASs. Wholly or partially overlapping domains are not within the
scope of this document. scope of this document.
1.1. Nested Domains 1.1. Nested Domains
skipping to change at line 106 skipping to change at line 157
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].
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 may apply to multiple TE LSP types. The choice may path computation techniques may apply to multiple TE LSP types. The
further depend on the application to which the TE LSPs are put and choice may further depend on the application to which the TE LSPs are
the nature, topology and switching capabilities of the network. put and the nature, topology and switching capabilities of the
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
Forwarding Adjacencies (FAs) are introduced and explained in detail Forwarding Adjacencies (FAs) are introduced and explained in detail
in [HIER]. No further description is necessary in this document. in [HIER]. No further description is necessary in this document.
skipping to change at line 141 skipping to change at line 193
The signaling trigger for the establishment of an FA LSP may be the The signaling trigger for the establishment of an FA LSP may be the
receipt of a signaling request for the TE LSP that it will carry, or 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 crossed may be a management action to 'pre-engineer' a domain to be crossed
by TE LSPs that would be used as FAs by the traffic that has to by TE LSPs that would be used as FAs by the traffic that has to
traverse the domain. Furthermore, the mapping (inheritance rules) traverse the domain. Furthermore, the mapping (inheritance rules)
between attributes of the nested and FA LSPs (including bandwidth) between attributes of the nested and FA LSPs (including bandwidth)
may be statically pre-configured or, for on-demand FA LSPs, may be may be statically pre-configured or, for on-demand FA LSPs, may be
dynamic according to the properties of the nested LSPs. dynamic according to the properties of the nested LSPs.
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 how or whether such an LSP could domains or parts of domains. However, how or whether such an LSP
be advertised as an FA that spans domains is open for study. The end could be advertised as an FA that spans domains is open for study.
points of a hierarchical LSP are not necessarily on domain The end points of a hierarchical LSP are not necessarily on domain
boundaries, so nesting is not limited to domain boundaries. boundaries, so nesting is not limited to domain boundaries.
Note also that the IGP/EGP routing topology is maintained unaffected Note also that the IGP/EGP routing topology is maintained unaffected
by the LSP connectivity and TE links introduced by FA LSPs. That is, by the LSP connectivity and TE links introduced by FA LSPs. That is,
the routing protocols do not exchange messages over the FA LSPs, and the routing protocols do not exchange messages over the FA LSPs, and
such LSPs do not create adjacencies between routers. During this such LSPs do not create routing adjacencies between routers.
operation the SENDER_TEMPLATE and SESSION objects remain unchanged
along the entire length of the LSP. During the operation of establishing a nested LSP that uses a
hierarchical LSP, the SENDER_TEMPLATE and SESSION objects remain
unchanged along the entire length of the nested LSP.
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 be single signaling exchange. No further LSPs are required to be
established to support this LSP. Signaling occurs between adjacent established to support this LSP. Signaling occurs between adjacent
neighbors only (no tunneling), and hop-by-hop signaling is used. neighbors only (no tunneling), and hop-by-hop signaling is used.
2.3. LSP Stitching 2.3. LSP Stitching
LSP Stitching is described in [STITCH].
In the LSP stitching model separate LSPs (referred to as a TE LSP In the LSP stitching model separate LSPs (referred to as a TE LSP
segments) are established and are "stitched" together in the data segments) are established and are "stitched" together in the data
plane so that a single end-to-end label switched path is achieved. plane so that a single end-to-end label switched path is achieved.
The distinction is that the component LSP segments are signaled as The distinction is that the component LSP segments are signaled as
distinct TE LSPs in the control plane. Each signaled TE LSP segment distinct TE LSPs in the control plane. Each signaled TE LSP segment
has a different source 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
setup request for TE LSP that it plans to stitch to a local TE LSP setup request for TE LSP that it plans to stitch to a local TE LSP
segment, or may be a management action. segment, or may be a management action.
LSP segments may be managed as FAs 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 indicated along the path perhaps through the various methods to be indicated along the path perhaps through the
RRO. 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.
skipping to change at line 221 skipping to change at line 279
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
vice versa. vice versa.
Any discussion of the appropriateness of a particular path Any discussion of the appropriateness of a particular path
computation technique in any given circumstance is beyond the scope computation technique in any given circumstance is beyond the scope
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.
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 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
skipping to change at line 246 skipping to change at line 306
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 is best if the ingress has full visibility The quality of this path (that is, its optimality as discussed in
into all relevant domains rather than just sufficient visibility to section 3.5) is best if the ingress has full visibility into all
provide some path to the destination. relevant domains rather than just sufficient visibility to provide
some path to the destination.
Extreme caution must be exercised in consideration of the Extreme caution must be exercised in consideration of the
distribution of the requisite TE information. See section 4. distribution of the requisite TE information. See section 4.
3.2.2. Partial Visibility Computation 3.2.2. Partial Visibility Computation
It may be that the ingress does not have full visibility of the It may be that the ingress does not have full visibility of the
topology of all domains, but does have information about the topology of all domains, but does have information about the
connectedness of the domains and the TE resource availability across connectedness of the domains and the TE resource availability across
the domains. In this case, the ingress is not able to provide a fully the domains. In this case, the ingress is not able to provide a fully
skipping to change at line 323 skipping to change at line 384
3.4. Path Computation Element 3.4. Path Computation Element
The computation techniques in sections 3.2 and 3.3 rely on topology The computation techniques in sections 3.2 and 3.3 rely on topology
and TE information being distributed to the ingress LSR and those and TE information being distributed to the ingress LSR and those
LSRs at domain boundaries. These LSRs are responsible for computing LSRs at domain boundaries. These LSRs are responsible for computing
paths. Note that there may be scaling concerns with distributing the paths. Note that there may be scaling concerns with distributing the
required information - see section 4. required information - see section 4.
An alternative technique places the responsibility for path An alternative technique places the responsibility for path
computation with a Path Computation Element (PCE). There may be computation with a Path Computation Element (PCE) [PCE]. There may be
either a centralized PCE, or multiple PCEs (each having a local either a centralized PCE, or multiple PCEs (each having local
visibility and collaborating in a distributed fashion to compute an visibility and collaborating in a distributed fashion to compute an
end to end path) across the entire network and even within any one end-to-end path) across the entire network and even within any one
domain. The PCE may collect topology and TE information from the same domain. The PCE may collect topology and TE information from the same
sources as would be used by LSRs in the paragraph, or though other sources as would be used by LSRs in the previous paragraph, or though
means. other means.
Each LSR called upon to perform path computation (and even the Each LSR called upon to perform path computation (and even the
offline management tools described in section 3.1) may abdicate the offline management tools described in section 3.1) may abdicate the
task to a PCE of its choice. The selection of PCE(s) may be driven by task to a PCE of its choice. The selection of PCE(s) may be driven by
static configuration or the dynamic discovery by means of IGP or BGP static configuration or the dynamic discovery by means of IGP or BGP
extensions. extensions.
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
skipping to change at line 377 skipping to change at line 438
the domain may consult its local PCE. the domain may consult its local PCE.
This mechanism could be used for all path computations within the This mechanism could be used for all path computations within the
domain, or specifically limited to computations for LSPs that will domain, or specifically limited to computations for LSPs that will
leave the domain where external connectivity information can then be leave the domain where external connectivity information can then be
restricted to just the PCE. restricted to just the PCE.
3.5. Optimal Path Computation 3.5. Optimal Path Computation
An optimal route might be defined as the route that would be computed An optimal route might be defined as the route that would be computed
in the absence of domain boundaries. It is easy to construct examples in the absence of domain boundaries. Another constraint to the
definition of 'optimal' might be to reduce or limit the number of
domains crossed by the LSP. It is easy to construct examples
that show that partitioning a network into domains, and the resulting that show that partitioning a network into domains, and the resulting
loss or aggregation of routing information may lead to the loss or aggregation of routing information may lead to the
computation of routes that are other than optimal. It is impossible computation of routes that are other than optimal. It is impossible
to guarantee optimal routing in the presence of aggregation / to guarantee optimal routing in the presence of aggregation /
abstraction / summarization of routing information. abstraction / summarization of routing information.
It is beyond the scope of this document to define what is an optimum It is beyond the scope of this document to define what is an optimum
path for an inter-domain TE LSP. This debate is abdicated in favor of path for an inter-domain TE LSP. This debate is abdicated in favor of
requirements documents and applicability statements. Note, however, requirements documents and applicability statements. Note, however,
that the meaning of certain computation metrics may differ between that the meaning of certain computation metrics may differ between
skipping to change at line 403 skipping to change at line 466
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 links to the corresponding domains. This would associated with the inter-domain links to the corresponding domains.
facilitate better path computation and reduce TE-related crankbacks This would facilitate better path computation and reduce TE-related
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 TEDB updates from a proxy within the domain. receive TEDB 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, and 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 FAs across other domains,
or the information may be aggregated or abstracted). or the information may be aggregated or abstracted).
Where any cross-domain reachability and TE information needs to be Where any cross-domain reachability and TE information needs to be
advertised, consideration must be given to TE extensions to BGP, and advertised, consideration must be given to TE extensions to BGP, and
how these may be fed to the IGPs. Techniques for inter-domain TE how these may be fed to the IGPs. Techniques for inter-domain TE
aggregation are also for further study. However, it must be noted aggregation are also for further study. However, it must be noted
that any extensions that cause a significant increase in the amount that any extensions that cause a significant increase in the amount
skipping to change at line 523 skipping to change at line 586
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 ([FRR]) 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 TE LSPs upon link/SRLG/Node failure. A msecs) of fast-reroutable TE LSPs upon link/SRLG/Node failure. A
backup TE LSP is configured and signaled at each hop, and activated backup TE LSP is configured and signaled at each hop, and activated
upon detecting or being informed of a network element failure. The upon detecting or being informed of a network element failure. The
node immediately upstream of the failure (called the PLR (Point of node immediately upstream of the failure (called the PLR - Point of
Local Repair)) reroutes the set of protected TE LSPs onto the Local Repair) reroutes the set of protected TE LSPs onto the
appropriate backup tunnel(s) and around the failed resource. 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 [FRR] specifies
two distinct modes of operation referred to as the "one to one mode" two distinct modes of operation referred to as the "one to one mode"
and the "facility back-up 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 PLR and the 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.
The techniques that must be employed to use Fast Reroute for the The techniques that must be employed to use Fast Reroute for the
different methods of signaling LSPs identified in section 2 differ different methods of signaling LSPs identified in section 2 differ
considerably. These should be explained further in applicability considerably. These should be explained further in applicability
statements of, in the case, of a change in base behavior, in statements of, in the case, of a change in base behavior, in
implementation guidelines specific to the signaling techniques. implementation guidelines specific to the signaling 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
skipping to change at line 554 skipping to change at line 622
considerably. These should be explained further in applicability considerably. These should be explained further in applicability
statements of, in the case, of a change in base behavior, in statements of, in the case, of a change in base behavior, in
implementation guidelines specific to the signaling techniques. implementation guidelines specific to the signaling 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
applicable to packet switching networks because other network
technologies cannot apply label stacking within the same switching
type. Segment protection [SEG-PROT] provides a suitable alternative
that is applicable to packet and non-packet networks.
5.5. Comments on Path Diversity 5.5. Comments on Path Diversity
Diverse paths may be required in support of load sharing and/or Diverse paths may be required in support of load sharing and/or
protection. Such diverse paths may be required to be node diverse, protection. Such diverse paths may be required to be node diverse,
link diverse, fully path diverse (that is, link and node diverse), or link diverse, fully path diverse (that is, link and node diverse), or
SRLG diverse. SRLG diverse.
Diverse path computation is a classic problem familiar to all graph Diverse path computation is a classic problem familiar to all graph
theory majors. The problem is compounded when there are areas of theory majors. The problem is compounded when there are areas of
'private knowledge' such as when domains do not share topology 'private knowledge' such as when domains do not share topology
information. The problem is generally considered to be easier and information. The problem is generally considered to be easier and
more efficient when the diverse paths can be computed more efficient when the diverse paths can be computed
'simultaneously' on the fullest set of information. That being said, 'simultaneously' on the fullest set of information. That being said,
various techniques (out of the scope of this document) exist to various techniques (out of the scope of this document) exist to
ensure end to end path diversity across multiple domains. ensure end-to-end path diversity across multiple 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
answered. There are two classes of SRLG:
- those that indicate resources that are all contained witin one
domain
- those that span domains.
The former might be identified using a combination of domain ID and
an SRLG ID that is administered by the domain. The latter requires
a wider scope to the SRLG ID, and it is not clear how this would be
administered.
5.6. Domain-Specific Constraints 5.6. Domain-Specific Constraints
While the meaning of certain constraints, like bandwidth, can be While the meaning of certain constraints, like bandwidth, can be
assumed to be constant across different domains, other TE constraints assumed to be constant across different domains, other TE constraints
(such as resource affinity, color, metric, priority, etc.) may have (such as resource affinity, color, metric, priority, etc.) may have
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. policy agreements between the Domain administrators. The details of
such a mapping function are outside the scope of this document, but
it is important to note that the default behavior MUST either be
that a constant mapping is applied or that any requirement to apply
these constraints across a domain boundary must fail in the absence
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 non case, when a TE LSP signaling attempt is rejected due to
compliance with some policy constraint, this SHOULD be reflected to non-compliance with some policy constraint, this SHOULD be reflected
the ingress LSR. to the ingress LSR.
5.8. Inter-domain OAM 5.8. Inter-domain 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 confidentiality are strong, collaboration between PCEs or domain
boundary nodes might be required in order to provide end-to-end OAM. boundary nodes might be required in order to provide end-to-end OAM.
The different signaling mechanisms described above may need The different signaling mechanisms described above may need
refinements to [LSPPING], [BFD-MPLS] or the use of [TUNTRACE] to gain refinements to [LSPPING], [BFD-MPLS] or the use of [TUNTRACE] to gain
full end-to-end visibility. These protocols should, however, be full end-to-end visibility. These protocols should, however, be
considered in the light of confidentiality requirements. considered in the light of 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 confidentiality or other policy
reasons. 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
Non-packet switching technologies may present particular issues for
inter-domain LSPs. While packet switching networks may utilize
control planes built on MPLS or GMPLS technology, non-packet networks
are limited to GMPLS.
The specific architectural considerations and requirements for
inter-domain LSP setup in non-packet networks are covered in a
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], but requirements for inter-domain security are, if
anything, more significant. anything, more significant.
Authentication techniques identified for use with RSVP-TE can only Authentication techniques identified for use with RSVP-TE can only
operate across domain boundaries if there is coordination between the operate across domain boundaries if there is coordination between the
administrators of those domains. administrators of those domains.
Confidentiality may also be considered to be security factors. Confidentiality may also be considered to be security factors.
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 are expected to contain
detailed security sections. detailed security sections.
7. Acknowledgements 7. IANA Considerations
This document makes no requests for any IANA action.
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 efforts on this document. Kompella for convincing them to expend effort on this document.
Grateful thanks to Dimitri Papadimitriou and Tomohiro Otani for their Grateful thanks to Dimitri Papadimitriou and Tomohiro Otani for their
review and suggestions on the text. review and suggestions on the text.
8. 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 674 skipping to change at line 781
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 this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
9. Normative References 10. 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.
[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.
[HIER] Kompella K., Rekhter Y., "LSP Hierarchy with [HIER] Kompella K., Rekhter Y., "LSP Hierarchy with
Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy-08. Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy,
txt, March 2002 (work in progress). work in progress.
[INTER-AREA] Le Roux, Vasseur et Boyle, "Requirements for support of [INTER-AREA] Le Roux, Vasseur et Boyle, "Requirements for support of
Inter-Area and Inter-AS MPLS Traffic Engineering", Inter-Area and Inter-AS MPLS Traffic Engineering",
draft-ietf-tewg-interarea-mpls-te-req-02.txt, June 2004 draft-ietf-tewg-interarea-mpls-te-req, work in
(work in progress). progress.
[INTER-AS] Zhang, R., Vasseur, JP. et al, "MPLS Inter-AS Traffic [INTER-AS] Zhang, R., Vasseur, JP. et al, "MPLS Inter-AS Traffic
Engineering requirements", Engineering requirements",
draft-ietf-tewg-interas-mpls-te-req-07.txt, June 2004 draft-ietf-tewg-interas-mpls-te-req, work in progress.
(work in progress).
10. Informational References [STITCH] Ayyangar, A., and Vasseur, JP., "LSP Stitching with
Generalized MPLS TE",
draft-ayyangar-ccamp-lsp-stitching, work in progress.
[PCE] Ash, G., Farrel, A., and Vasseur, JP., "Path
Computation Element (PCE) Architecture",
draft-ash-pce-architecture, work in progress.
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 [ATTRIB] 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-03.txt, March 2004 draft-ietf-mpls-rsvpte-attributes, work in progress.
(work in progress).
[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-01.txt, MPLS Signaling", draft-ietf-ccamp-crankback,
January 2004 (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-01.txt, December draft-ietf-ccamp-rsvp-te-exclude-route, work in
2003 (work in progress). progress.
[FRR] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE [FRR] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE
for LSP Tunnels", for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute,
draft-ietf-mpls-rsvp-lsp-fastreroute-06.txt, work in progress.
(work in progress).
[GMPLS-AS] Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS
Traffic Engineering Requirements",
draft-otani-ccamp-interas-GMPLS-TE, work in progress.
[LSPPING] Kompella, K., et al., " Detecting Data Plane Liveliness [LSPPING] Kompella, K., et al., " Detecting Data Plane Liveliness
in MPLS", Internet Draft in MPLS", draft-ietf-mpls-lsp-ping, work in progress.
draft-ietf-mpls-lsp-ping-05.txt, February 2004 (work in
progress).
[MRN] Papadimitriou, D., et al., "Generalized MPLS [MRN] K. Shiomoto, et al., "Requirements for GMPLS-based
Architecture for Multi-Region Networks", multi-region and multi-layer networks",
draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt, draft-shiomoto-ccamp-gmpls-mrn-reqs, work in progress.
February 2004 (work in progress).
[OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay [OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay
Model", draft-ietf-ccamp-gmpls-overlay-04.txt, April Model", draft-ietf-ccamp-gmpls-overlay, work in
2004 (work in progress). progress.
[SEG-PROT] Berger, L., Bryskin, I., Papadimitriou, D. and Farrel,
A., "GMPLS Based Segment Recovery",
draft-ietf-ccamp-gmpls-segment-recovery, work in
progress.
[TUNTRACE] Bonica, R., et al., "Generic Tunnel Tracing Protocol [TUNTRACE] Bonica, R., et al., "Generic Tunnel Tracing Protocol
(GTTP) Specification", draft-ietf-ccamp-tunproto-00, (GTTP) Specification", draft-ietf-ccamp-tunproto,
March 2004 (work in progress). work in progress.
11. 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 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
Arthi Ayyangar Arthi Ayyangar
Juniper Networks, Inc Juniper Networks, Inc
1194 N.Mathilda Ave 1194 N.Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Email: arthi@juniper.net Email: arthi@juniper.net
12. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). 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. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/