draft-ietf-ccamp-inter-domain-framework-02.txt   draft-ietf-ccamp-inter-domain-framework-03.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: November 2005 Jean-Philippe Vasseur Expires: December 2005 Jean-Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
Arthi Ayyangar Arthi Ayyangar
Juniper Networks Juniper Networks
May 2005 June 2005
A Framework for Inter-Domain MPLS Traffic Engineering A Framework for Inter-Domain MPLS Traffic Engineering
draft-ietf-ccamp-inter-domain-framework-02.txt draft-ietf-ccamp-inter-domain-framework-03.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 48 skipping to change at line 48
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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. Traffic Engineered (TE) 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 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 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 ......................................... 5 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 ............................... 6 3.1. Management Configuration ............................... 7
3.2. Head End Computation ................................... 6 3.2. Head End Computation ................................... 7
3.2.1. Multi-Domain Visibility Computation ................ 7 3.2.1. Multi-Domain Visibility Computation ................ 7
3.2.2. Partial Visibility Computation ..................... 7 3.2.2. Partial Visibility Computation ..................... 7
3.2.3. Local Domain Visibility Computation ................ 7 3.2.3. Local Domain Visibility Computation ................ 8
3.3. Domain Boundary Computation ............................ 8 3.3. Domain Boundary Computation ............................ 8
3.4. Path Computation Element ............................... 8 3.4. Path Computation Element ............................... 9
3.4.1. Multi-Domain Visibility Computation ................ 9 3.4.1. Multi-Domain Visibility Computation ................ 9
3.4.2. Path Computation Use of PCE When Preserving 3.4.2. Path Computation Use of PCE When Preserving
Confidentiality .................................... 9 Confidentiality .................................... 9
3.4.3. Per-Domain Computation Servers ..................... 9 3.4.3. Per-Domain Computation Servers .................... 10
3.5. Optimal Path Computation ............................... 9 3.5. Optimal Path Computation .............................. 10
4. Distributing Reachability and TE Information .............. 10 4. Distributing Reachability and TE Information .............. 10
5. Comments on Advanced Functions ............................ 11 5. Comments on Advanced Functions ............................ 11
5.1. LSP Re-Optimization ................................... 11 5.1. LSP Re-Optimization ................................... 12
5.2. LSP Setup Failure ..................................... 12 5.2. LSP Setup Failure ..................................... 12
5.3. LSP Repair ............................................ 12 5.3. LSP Repair ............................................ 13
5.4. Fast Reroute .......................................... 12 5.4. Fast Reroute .......................................... 13
5.5. Comments on Path Diversity ............................ 13 5.5. Comments on Path Diversity ............................ 14
5.6. Domain-Specific Constraints ........................... 14 5.6. Domain-Specific Constraints ........................... 15
5.7. Policy Control ........................................ 14 5.7. Policy Control ........................................ 16
5.8. Inter-domain OAM ...................................... 15 5.8. Inter-domain OAM ...................................... 16
5.9. Point-to-Multipoint ................................... 15 5.9. Point-to-Multipoint ................................... 16
5.10. Applicability to Non-Packet Technologies ............. 15 5.10. Applicability to Non-Packet Technologies ............. 16
6. Security Considerations ................................... 15 6. Security Considerations ................................... 17
7. IANA Considerations ....................................... 16 7. IANA Considerations ....................................... 17
8. Acknowledgements .......................................... 16 8. Acknowledgements .......................................... 17
9. Intellectual Property Considerations ...................... 16 9. Intellectual Property Considerations ...................... 17
10. Normative References ..................................... 16 10. Normative References ..................................... 18
11. Informational References ................................. 17 11. Informational References ................................. 18
12. Authors' Addresses ....................................... 18 12. Authors' Addresses ....................................... 19
13. Full Copyright Statement ................................. 19 13. Full Copyright Statement ................................. 20
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 Traffic
across multiple domains. The functional components of these Engineered (TE) Label Switched Paths (LSPs) across multiple domains.
techniques are separated into the mechanisms for discovering In this context and within the remainder of this document, we
reachability and TE information, for computing the paths of LSPs, and consider all source-based and constraint-based routed LSPs and refer
for signaling the LSPs. Note that the aim of this document is not to to them interchangeably as "TE LSPs" or "LSPs".
detail each of those techniques which are covered in separate
documents, but rather to propose a framework for inter-domain MPLS
Traffic Engineering.
Note that in the remainder of this document, the term 'MPLS Traffic The functional components of these techniques are separated into the
Engineering' is used equally to apply to MPLS and GMPLS traffic. mechanisms for discovering reachability and TE information, for
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
which are covered in separate documents referenced from the sections
of this document that introduce the techniques, but rather to propose
a framework for inter-domain MPLS 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.
Specific issues pertaining to the use of GMPLS in inter-domain Specific issues pertaining to the use of GMPLS in inter-domain
environments (for example, policy implications of the use of the Link environments (for example, policy implications of the use of the Link
Management Protocol [LMP] on inter-domain links) these are covered in Management Protocol [LMP] on inter-domain links) these are covered in
a separate document. 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. However, domains of domains include IGP areas and Autonomous Systems. Wholly or partially
computational responsibility may also exist as sub-domains of areas overlapping domains (e.g. path computation sub-domains of areas or
or ASs. Wholly or partially overlapping domains are not within the ASs) are not within the scope of this document.
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 In the context of MPLS TE, domain A is considered to be nested within
domain B if domain A is wholly contained in Domain B, and domain B is domain B if domain A is wholly contained in Domain B, and domain B is
fully or partially aware of the TE characteristics and topology of fully or partially aware of the TE characteristics and topology of
domain A. domain A.
For further consideration of nested domains see [MRN]
1.2. Conventions used in this document 1.2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
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 TE LSP types. The path computation techniques may apply to multiple signaling options.
choice may further depend on the application to which the TE LSPs are The choice may further depend on the application to which the TE LSPs
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
Forwarding Adjacencies (FAs) are introduced and explained in detail Hierarchical LSPs form a fundamental part of MPLS [RFC3031] and are
in [HIER]. No further description is necessary in this document. discussed in further detail in [HIER]. Hierarchical LSPs may
optionally be advertised as TE links. Note that a hierarchical LSP
that spans multiple domains cannot be advertised in this way because
there is no concept of TE information that spans domains.
FAs can be used in support of inter-domain TE LSPs. In particular, an Hierarchical LSPs can be used in support of inter-domain TE LSPs.
FA may be used to achieve connectivity between any pair of LSRs In particular, a hierarchical LSP may be used to achieve connectivity
within a domain. The ingress and egress of the FA LSP could be the between any pair of LSRs within a domain. The ingress and egress of
edge nodes of the domain in which case connectivity is achieved the hierarchical LSP could be the edge nodes of the domain in which
across the entire domain, or they could be any other pair of LSRs in case connectivity is achieved across the entire domain, or they could
the domain. 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. An FA may provide a TE LSP tunnel to transport (i.e. nest) nesting. A hierarchical LSP may provide a TE LSP tunnel to transport
multiple TE LSPs along a common part of their paths. Alternatively, a (i.e. nest) multiple TE LSPs along a common part of their paths.
TE LSP may carry (i.e. nest) a single LSP in a one-to-one mapping. Alternatively, a TE LSP may carry (i.e. nest) a single LSP in a
one-to-one mapping.
The signaling trigger for the establishment of an FA LSP may be the The signaling trigger for the establishment of a hierarchical LSP may
receipt of a signaling request for the TE LSP that it will carry, or be the receipt of a signaling request for the TE LSP that it will
may be a management action to 'pre-engineer' a domain to be crossed carry, or may be a management action to "pre-engineer" a domain to be
by TE LSPs that would be used as FAs by the traffic that has to crossed by TE LSPs that would be used as hierarchical LSPs by the
traverse the domain. Furthermore, the mapping (inheritance rules) traffic that has to traverse the domain. Furthermore, the mapping
between attributes of the nested and FA LSPs (including bandwidth) (inheritance rules) between attributes of the nested and the
may be statically pre-configured or, for on-demand FA LSPs, may be hierarchical LSPs (including bandwidth) may be statically
dynamic according to the properties of the nested LSPs. pre-configured or, for on-demand hierarchical LSPs, may be 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
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, how or whether such an LSP domains or parts of domains. However, such an LSP cannot be
could be advertised as an FA that spans domains is open for study. advertised as a TE link that spans domains. The end points of a
The end points of a hierarchical LSP are not necessarily on domain hierarchical LSP are not necessarily on domain boundaries, so nesting
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 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 hierarchical LSPs
the routing protocols do not exchange messages over the FA LSPs, and even if they are advertised as TE links. That is, the routing
such LSPs do not create routing adjacencies between routers. protocols do not exchange messages 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. unchanged along the entire length of the nested LSP, as do all other
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. Signaling occurs between adjacent established to support this LSP so that hierarchical or stitched LSPs
neighbors only (no tunneling), and hop-by-hop signaling is used. are not needed.
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
different LSPs, or of "shuffling" Session or LSP identifiers is not
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 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
skipping to change at line 237 skipping to change at line 254
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 a 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. 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 indicated along the path perhaps through the various methods to be reported 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.
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 [ATTRIB]. 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. interoperability since new mechanisms must be backwards compatible,
and care must be taken to avoid allowing standards-conformant
implementations each supporting a different functional subset such
that they are not capable of estbalishing 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 310 skipping to change at line 330
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) is best if the ingress has full visibility into all section 3.5) can be better if the ingress has full visibility into
relevant domains rather than just sufficient visibility to provide all relevant domains rather than just sufficient visibility to
some path to the destination. 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
specified strict explicit path from ingress to egress. However, the specified strict explicit path from ingress to egress. However, for
ingress can supply an explicit path that comprises: example, the ingress might supply an explicit path that comprises:
- explicit hops from ingress to the local domain boundary - explicit hops from ingress to the local domain boundary
- loose hops representing the domain entry points across the network - loose hops representing the domain entry points across the network
- a loose hop identifying the egress. - a loose hop identifying the egress.
Alternatively, the explicit path may be expressed as: Alternatively, the explicit path might be expressed as:
- explicit hops from ingress to the local domain boundary - explicit hops from ingress to the local domain boundary
- strict hops giving abstract nodes representing each domain in turn - strict hops giving abstract nodes representing each domain in turn
- a loose hop identifying the egress. - a loose hop identifying the egress.
These two explicit path formats may be mixed. These two explicit path formats could be mixed according to the
information available resulting in different combinations of loose
hops and abstract nodes.
This form of explicit path relies on some further computation This form of explicit path relies on some further computation
technique being applied at the domain boundaries. See section 3.3. technique being applied at the domain boundaries. See section 3.3.
As with the multi-domain visibility option, extreme caution must be As with the multi-domain visibility option, extreme caution must be
exercised in consideration of the distribution of the requisite TE exercised in consideration of the distribution of the requisite TE
information. See section 4. information. See section 4.
3.2.3. Local Domain Visibility Computation 3.2.3. Local Domain Visibility Computation
skipping to change at line 398 skipping to change at line 420
either a centralized PCE, or multiple PCEs (each having 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 previous paragraph, or though sources as would be used by LSRs in the previous paragraph, or though
other 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.
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
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
skipping to change at line 421 skipping to change at line 442
desirable (e.g to preserve confidentiality) that the full path is not desirable (e.g to preserve confidentiality) that the full path is not
provided to the ingress LSR. Instead, a partial path is supplied (as provided to the ingress LSR. Instead, a partial path is supplied (as
in section 3.2.2 or 3.2.3) and the LSRs at each domain boundary are in section 3.2.2 or 3.2.3) and the LSRs at each domain boundary are
required to make further requests for each successive segment of the required to make further requests for each successive segment of the
path. 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 the best path on each request or at regular intervals. recompute each leg of the path on each request or at regular
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
normally operational between domains. normally operational between domains.
3.4.3. Per-Domain Computation Elements 3.4.3. Per-Domain Computation Elements
A third way that PCEs may be used is simply to have one (or more) per A third way that PCEs may be used is simply to have one (or more) per
domain. Each LSR within a domain that wishes to derive a path across domain. Each LSR within a domain that wishes to derive a path across
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 There are many definitions of an optimal path depending on the
in the absence of domain boundaries. Another constraint to the constraints applied to the path computation. In a multi-domain
definition of 'optimal' might be to reduce or limit the number of environment the definitions are multiplied so that an optimal route
domains crossed by the LSP. It is easy to construct examples might be defined as the route that would be computed in the absence
that show that partitioning a network into domains, and the resulting of domain boundaries. Alternatively, another constraint might be
loss or aggregation of routing information may lead to the applied to the path computation to reduce or limit the number of
computation of routes that are other than optimal. It is impossible domains crossed by the LSP.
to guarantee optimal routing in the presence of aggregation /
abstraction / summarization of routing information. It is easy to construct examples that show that partitioning a
network into domains, and the resulting loss or aggregation of
routing information may lead to the computation of routes that are
other than optimal. It is impossible to guarantee optimal routing in
the presence of aggregation / 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 for specific
that the meaning of certain computation metrics may differ between deployment scenarios. Note, however, that the meaning of certain
domains (see section 5.6). computation metrics may differ between domains (see section 5.6).
4. Distributing Reachability and TE Information 4. Distributing Reachability and TE Information
Traffic Engineering information is collected into a TE Database (TED) Traffic Engineering information is collected into a TE Database (TED)
on which path computation algorithms operate either directly or by on which path computation algorithms operate either directly or by
first constructing a network graph. first constructing a network graph.
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
skipping to change at line 493 skipping to change at line 520
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 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 Before starting work on any protocols or protocol extensions to
advertised, consideration must be given to TE extensions to BGP, and enable cross-domain reachability and TE advertisement in support of
how these may be fed to the IGPs. Techniques for inter-domain TE inter-domain TE, the requirements and and benefits must be clearly
aggregation are also for further study. However, it must be noted established. This has not been done to date. Where any cross-domain
that any extensions that cause a significant increase in the amount reachability and TE information needs to be advertised, consideration
of processing (such as aggregation computation) at domain boundaries, must be given to TE extensions to existing protocols such as BGP, and
or a significant increase in the amount of information flooded (such how the information advertised may be fed to the IGPs. It must be
as detailed TE information) need to be treated with extreme caution noted that any extensions that cause a significant increase in the
and compared carefully with the scaling requirements expressed in amount of processing (such as aggregation computation) at domain
[INTER-AREA] and [INTER-AS]. boundaries, or a significant increase in the amount of information
flooded (such as detailed TE information) need to be treated with
extreme caution and compared carefully with the scaling requirements
expressed in [INTER-AREA] and [INTER-AS].
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.
5.1. LSP Re-Optimization 5.1. LSP Re-Optimization
Re-optimization is the process of moving a TE LSP from one path to Re-optimization is the process of moving a TE LSP from one path to
another, more preferable path (where no attempt is made in this another, more preferable path (where no attempt is made in this
document to define 'preferable' as no attempt was made to define document to define "preferable" as no attempt was made to define
'optimal'). Make-before-break techniques are usually applied to "optimal"). Make-before-break techniques are usually applied to
ensure that traffic is disrupted as little as possible. The Shared ensure that traffic is disrupted as little as possible. The Shared
Explicit style is usually used to avoid double booking of network Explicit style is usually used to avoid double booking of network
resources. resources.
Re-optimization may be available within a single domain. Re-optimization may be available within a single domain.
Alternatively, re-optimization may involve a change in route across Alternatively, re-optimization may involve a change in route across
several domains or might involve a choice of different transit several domains or might involve a choice of different transit
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
skipping to change at line 541 skipping to change at line 571
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 diverse paths are applied end-to-end Note also that where multiple mutually-diverse paths are applied
(i.e. not simply within protection domains - see section 5.5) the end-to-end (i.e. not simply within protection domains - see section
point of calculation for re-optimization (whether it is PCE, ingress, 5.5) the point of calculation for re-optimization (whether it is PCE,
or domain entry point) needs to know all such paths before attempting ingress, or domain entry point) needs to know all such paths before
re-optimization of any one path. attempting re-optimization of any one path. Mutual diversity here
means that a set of computed paths have no commonality. Such
diversity might be link, node, SRLG or even 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 600 skipping to change at line 633
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 ([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 packet-based TE LSPs upon link/SRLG/Node
backup TE LSP is configured and signaled at each hop, and activated failure. A backup TE LSP is configured and signaled at each hop, and
upon detecting or being informed of a network element failure. The activated upon detecting or being informed of a network element
node immediately upstream of the failure (called the PLR - Point of failure. The node immediately upstream of the failure (called the PLR
Local Repair) reroutes the set of protected TE LSPs onto the - Point of Local Repair) reroutes the set of protected TE LSPs onto
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 [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.
skipping to change at line 627 skipping to change at line 660
- 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 Although it may be possible to apply the same techniques for FRR to
different methods of signaling LSPs identified in section 2 differ the different methods of signaling inter-domain LSPs described in
considerably. These should be explained further in applicability section 2, the results of protection may be different when it is the
statements of, in the case, of a change in base behavior, in boundary nodes that need to be protected, and when they are the
implementation guidelines specific to the signaling techniques. ingress and egress of a hierarchical LSP or stitched LSP segment. In
particular, the choice of Point of Local Repair (PLR) and Merge Point
(MP) may be different, and the length of the protection path may be
greater. These use of FRR techniques should be explained further in
applicability statements or, in the case of a change in base
behavior, in 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 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 654 skipping to change at line 693
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 can be resolved more efficiently (e.g.
more efficient when the diverse paths can be computed avoiding the "trap problem") when mutually resource disjoint paths
'simultaneously' on the fullest set of information. That being said, can be computed "simultaneously" on the fullest set of information.
various techniques (out of the scope of this document) exist to
ensure end-to-end path diversity across multiple domains.
Many network technologies utilize 'protection domains' because they That being said, various techniques (out of the scope of this
document) exist to ensure end-to-end path diversity across multiple
domains.
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 witin one
domain domain
- those that span domains. - those that span domains.
The former might be identified using a combination of domain ID and The former might be identified using a combination of a globally
an SRLG ID that is administered by the domain. The latter requires scoped domain ID, and an SRLG ID that is administered by the domain.
a wider scope to the SRLG ID, and it is not clear how this would be The latter requires a global scope to the SRLG ID. Both schemes,
administered. therefore, require external administration. The former is able to
leverage existing domain ID administration (for example, area and AS
numbers), but the latter would require a new administrative policy.
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
skipping to change at line 716 skipping to change at line 759
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 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,
and a significant issue to be resolved is to ensure 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 [LSPPING], 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 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
skipping to change at line 742 skipping to change at line 787
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
inter-domain LSPs. While packet switching networks may utilize inter-domain LSPs. While packet switching networks may utilize
control planes built on MPLS or GMPLS technology, non-packet networks control planes built on MPLS or GMPLS technology, non-packet networks
are limited to GMPLS. are limited to GMPLS.
On the other hand, some problems such as Fast Re-Route on domain
boundaries (see section 5.4) may be handled by the GMPLS technique of
segment protection [GMPLS-SEG] that is applicable to both packet and
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], but requirements for inter-domain security are, if
anything, more significant. anything, more significant.
skipping to change at line 771 skipping to change at line 821
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 and Tomohiro Otani for their Grateful thanks to Dimitri Papadimitriou, Tomohiro Otani and Igor
review and suggestions on the text. Bryskin for their review and suggestions on 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
skipping to change at line 803 skipping to change at line 853
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 [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.
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon,
"Multiprotocol Label Switching Architecture", RFC 3031,
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.
skipping to change at line 865 skipping to change at line 919
draft-ietf-tewg-interarea-mpls-te-req, work in draft-ietf-tewg-interarea-mpls-te-req, 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, work in progress. draft-ietf-tewg-interas-mpls-te-req, work in progress.
[LSPPING] Kompella, K., et al., " Detecting Data Plane Liveliness [LSPPING] Kompella, K., et al., " Detecting Data Plane Liveliness
in MPLS", draft-ietf-mpls-lsp-ping, work in progress. in MPLS", draft-ietf-mpls-lsp-ping, work in progress.
[MRN] K. Shiomoto, et al., "Requirements for GMPLS-based
multi-region and multi-layer networks",
draft-shiomoto-ccamp-gmpls-mrn-reqs, 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, work in Model", draft-ietf-ccamp-gmpls-overlay, work in
progress. progress.
[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.
[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",
 End of changes. 

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