draft-ietf-ccamp-inter-domain-framework-01.txt   draft-ietf-ccamp-inter-domain-framework-02.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: August 2005 Jean-Philippe Vasseur Expires: November 2005 Jean-Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
Arthi Ayyangar Arthi Ayyangar
Juniper Networks Juniper Networks
February 2005 May 2005
A Framework for Inter-Domain MPLS Traffic Engineering A Framework for Inter-Domain MPLS Traffic Engineering
draft-ietf-ccamp-inter-domain-framework-01.txt
draft-ietf-ccamp-inter-domain-framework-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. 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."
skipping to change at line 57 skipping to change at line 57
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 Contents
1. Introduction ............................................... 1. Introduction ............................................... 3
1.1. Nested Domains ......................................... 1.1. Nested Domains ......................................... 3
1.2. Conventions used in this document ...................... 1.2. Conventions used in this document ...................... 4
2. Signaling Options .......................................... 2. Signaling Options .......................................... 4
2.1. LSP Nesting ............................................ 2.1. LSP Nesting ............................................ 4
2.2. Contiguous LSP ......................................... 2.2. Contiguous LSP ......................................... 5
2.3. LSP Stitching .......................................... 2.3. LSP Stitching .......................................... 5
2.4. Hybrid Methods ......................................... 2.4. Hybrid Methods ......................................... 5
2.5. Control of Downstream Choice of Signaling Method ....... x 2.5. Control of Downstream Choice of Signaling Method ....... 6
3. Path Computation Techniques ................................ 3. Path Computation Techniques ................................ 6
3.1. Management Configuration ............................... 3.1. Management Configuration ............................... 6
3.2. Head End Computation ................................... 3.2. Head End Computation ................................... 6
3.2.1. Multi-Domain Visibility Computation ................ 3.2.1. Multi-Domain Visibility Computation ................ 7
3.2.2. Partial Visibility Computation ..................... 3.2.2. Partial Visibility Computation ..................... 7
3.2.3. Local Domain Visibility Computation ................ 3.2.3. Local Domain Visibility Computation ................ 7
3.3. Domain Boundary Computation ............................ 3.3. Domain Boundary Computation ............................ 8
3.4. Path Computation Element ............................... 3.4. Path Computation Element ............................... 8
3.4.1. Multi-Domain Visibility Computation ................ 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 .................................... Confidentiality .................................... 9
3.4.3. Per-Domain Computation Servers ..................... 3.4.3. Per-Domain Computation Servers ..................... 9
3.5. Optimal Path Computation ............................... 3.5. Optimal Path Computation ............................... 9
4. Distributing Reachability and TE Information ............... 4. Distributing Reachability and TE Information .............. 10
5. Comments on Advanced Functions ............................. 5. Comments on Advanced Functions ............................ 11
5.1. LSP Re-Optimization .................................... 5.1. LSP Re-Optimization ................................... 11
5.2. LSP Setup Failure ...................................... 5.2. LSP Setup Failure ..................................... 12
5.3. LSP Repair ............................................. 5.3. LSP Repair ............................................ 12
5.4. Fast Reroute ........................................... 5.4. Fast Reroute .......................................... 12
5.5. Comments on Path Diversity ............................. 5.5. Comments on Path Diversity ............................ 13
5.6. Domain-Specific Constraints ............................ 5.6. Domain-Specific Constraints ........................... 14
5.7. Policy Control ......................................... 5.7. Policy Control ........................................ 14
5.8. Inter-domain OAM ....................................... 5.8. Inter-domain OAM ...................................... 15
5.9. Point-to-Multipoint .................................... 5.9. Point-to-Multipoint ................................... 15
5.10. Applicability to Non-Packet Technologies .............. 5.10. Applicability to Non-Packet Technologies ............. 15
6. Security Considerations .................................... 6. Security Considerations ................................... 15
7. IANA Considerations ........................................ 7. IANA Considerations ....................................... 16
8. Acknowledgements ........................................... 8. Acknowledgements .......................................... 16
9. Intellectual Property Considerations ....................... 9. Intellectual Property Considerations ...................... 16
10. Normative References ...................................... 10. Normative References ..................................... 16
11. Informational References .................................. 11. Informational References ................................. 17
12. Authors' Addresses ........................................ 12. Authors' Addresses ....................................... 18
13. Full Copyright Statement .................................. 13. Full Copyright Statement ................................. 19
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.
skipping to change at line 120 skipping to change at line 120
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 of 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 Note that in the remainder of this document, the term 'MPLS Traffic
Engineering' is used equally to apply to MPLS and GMPLS traffic Engineering' is used equally to apply to MPLS and GMPLS traffic.
engineering in packet and non-packet environments. Specific issues pertaining to the use of GMPLS in inter-domain
environments (for example, policy implications of the use of the Link
Management Protocol [LMP] on inter-domain links) these are covered in
a separate document.
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 424 skipping to change at line 427
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 the best path on each request or at regular intervals.
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 Servers 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.
skipping to change at line 455 skipping to change at line 458
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
domains (see section 5.6). 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)
on which path computation algorithms operate either directly or by
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
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),
skipping to change at line 477 skipping to change at line 484
This would facilitate better path computation and reduce TE-related This would facilitate better path computation and reduce TE-related
crankbacks on these links. crankbacks on these links.
Where a domain is a subset of an IGP area, filtering of TE Where a domain is a subset of an IGP area, filtering of TE
information may be applied at the domain boundary. This filtering may information may be applied at the domain boundary. This filtering may
be one way, or two way. be one way, or two way.
Where information needs to reach a PCE that spans multiple domains, Where information needs to reach a PCE that spans multiple domains,
the PCE may snoop on the IGP traffic in each domain, or play an the PCE may snoop on the IGP traffic in each domain, or play an
active part as an IGP-capable node in each domain. The PCE might also active part as an IGP-capable node in each domain. The PCE might also
receive TEDB 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 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
skipping to change at line 528 skipping to change at line 535
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
re-computed. The techniques used may be selected as described in re-computed. The techniques used may be selected as described in
section 3, and this will influence whether the whole or part of the section 3, and this will influence whether the whole or part of the
path is re-optimized. path is re-optimized.
The trigger for path computation and re-optimization may be an The trigger for path computation and re-optimization may be an
operator request, a timer, or information about a change in operator request, a timer, information about a change in
availability of network resources. This trigger MUST be applied to availability of network resources, or a change in operational
the point in the network that requests re-computation and controls parameters (for example bandwidth) of an LSP. This trigger MUST be
re-optimization and may require additional signaling. applied to the point in the network that requests re-computation and
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 diverse paths are applied end-to-end
(i.e. not simply within protection domains - see section 5.5) the (i.e. not simply within protection domains - see section 5.5) the
point of calculation for re-optimization (whether it is PCE, ingress, point of calculation for re-optimization (whether it is PCE, ingress,
or domain entry point) needs to know all such paths before attempting or domain entry point) needs to know all such paths before attempting
re-optimization of any one path. re-optimization of any one path.
It may be the case that re-optimization is best achieved by
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
simply those LSPs that originate at a particular ingress. While this
problem is inherited from single domain re-optimization and is out of
scope within this document, it should be noted that the problem grows
in complexity when LSPs wholly within one domain affect the
re-optimization path calculations performed in another domain.
5.2. LSP Setup Failure 5.2. LSP Setup Failure
When an inter-domain LSP setup fails in some domain other than the When an inter-domain LSP setup fails in some domain other than the
first, various options are available for reporting and retrying the first, various options are available for reporting and retrying the
LSP. LSP.
In the first instance, a retry may be attempted within the domain In the first instance, a retry may be attempted within the domain
that contains the failure. That retry may be attempted by nodes that contains the failure. That retry may be attempted by nodes
wholly within the domain, or the failure may be referred back to the wholly within the domain, or the failure may be referred back to the
LSR at the domain boundary. LSR at the domain boundary.
skipping to change at line 702 skipping to change at line 719
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], and [BFD-MPLS], etc., to gain full
full end-to-end visibility. These protocols should, however, be end-to-end visibility. These protocols should, however, be considered
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
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
skipping to change at line 800 skipping to change at line 817
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
Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy,
work in progress.
[INTER-AREA] Le Roux, Vasseur et Boyle, "Requirements for support of
Inter-Area and Inter-AS MPLS Traffic Engineering",
draft-ietf-tewg-interarea-mpls-te-req, work in
progress.
[INTER-AS] Zhang, R., Vasseur, JP. et al, "MPLS Inter-AS Traffic
Engineering requirements",
draft-ietf-tewg-interas-mpls-te-req, work in progress.
[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 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, work in progress. draft-ietf-mpls-rsvpte-attributes, 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, MPLS Signaling", draft-ietf-ccamp-crankback,
skipping to change at line 852 skipping to change at line 849
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", draft-ietf-mpls-rsvp-lsp-fastreroute, for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute,
work in progress. work in progress.
[GMPLS-AS] Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS [GMPLS-AS] Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS
Traffic Engineering Requirements", Traffic Engineering Requirements",
draft-otani-ccamp-interas-GMPLS-TE, work in progress. draft-otani-ccamp-interas-GMPLS-TE, work in progress.
[HIER] Kompella K., Rekhter Y., "LSP Hierarchy with
Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy,
work in progress.
[INTER-AREA] Le Roux, Vasseur et Boyle, "Requirements for support of
Inter-Area and Inter-AS MPLS Traffic Engineering",
draft-ietf-tewg-interarea-mpls-te-req, work in
progress.
[INTER-AS] Zhang, R., Vasseur, JP. et al, "MPLS Inter-AS Traffic
Engineering requirements",
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 [MRN] K. Shiomoto, et al., "Requirements for GMPLS-based
multi-region and multi-layer networks", multi-region and multi-layer networks",
draft-shiomoto-ccamp-gmpls-mrn-reqs, work in progress. 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
Computation Element (PCE) Architecture",
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",
draft-ietf-ccamp-gmpls-segment-recovery, work in draft-ietf-ccamp-gmpls-segment-recovery, work in
progress. progress.
[TUNTRACE] Bonica, R., et al., "Generic Tunnel Tracing Protocol [STITCH] Ayyangar, A., and Vasseur, JP., "LSP Stitching with
(GTTP) Specification", draft-ietf-ccamp-tunproto, Generalized MPLS TE",
work in progress. draft-ietf-ccamp-lsp-stitching, work in progress.
12. Authors' Addresses 12. Authors' Addresses
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Jean-Philippe Vasseur Jean-Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
 End of changes. 

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