--- 1/draft-ietf-ccamp-inter-domain-framework-01.txt 2006-02-04 22:57:08.000000000 +0100 +++ 2/draft-ietf-ccamp-inter-domain-framework-02.txt 2006-02-04 22:57:08.000000000 +0100 @@ -1,32 +1,32 @@ + Network Working Group Adrian Farrel IETF Internet Draft Olddog Consulting Proposed Status: Informational -Expires: August 2005 Jean-Philippe Vasseur +Expires: November 2005 Jean-Philippe Vasseur Cisco Systems, Inc. Arthi Ayyangar Juniper Networks - February 2005 + May 2005 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 - This document is an Internet-Draft and is subject to all provisions - of Section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." @@ -47,62 +47,62 @@ Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs) in multi-domain networks. For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such 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 ................ + 1. Introduction ............................................... 3 + 1.1. Nested Domains ......................................... 3 + 1.2. Conventions used in this document ...................... 4 + 2. Signaling Options .......................................... 4 + 2.1. LSP Nesting ............................................ 4 + 2.2. Contiguous LSP ......................................... 5 + 2.3. LSP Stitching .......................................... 5 + 2.4. Hybrid Methods ......................................... 5 + 2.5. Control of Downstream Choice of Signaling Method ....... 6 + 3. Path Computation Techniques ................................ 6 + 3.1. Management Configuration ............................... 6 + 3.2. Head End Computation ................................... 6 + 3.2.1. Multi-Domain Visibility Computation ................ 7 + 3.2.2. Partial Visibility Computation ..................... 7 + 3.2.3. Local Domain Visibility Computation ................ 7 + 3.3. Domain Boundary Computation ............................ 8 + 3.4. Path Computation Element ............................... 8 + 3.4.1. Multi-Domain Visibility Computation ................ 9 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 .................................. + Confidentiality .................................... 9 + 3.4.3. Per-Domain Computation Servers ..................... 9 + 3.5. Optimal Path Computation ............................... 9 + 4. Distributing Reachability and TE Information .............. 10 + 5. Comments on Advanced Functions ............................ 11 + 5.1. LSP Re-Optimization ................................... 11 + 5.2. LSP Setup Failure ..................................... 12 + 5.3. LSP Repair ............................................ 12 + 5.4. Fast Reroute .......................................... 12 + 5.5. Comments on Path Diversity ............................ 13 + 5.6. Domain-Specific Constraints ........................... 14 + 5.7. Policy Control ........................................ 14 + 5.8. Inter-domain OAM ...................................... 15 + 5.9. Point-to-Multipoint ................................... 15 + 5.10. Applicability to Non-Packet Technologies ............. 15 + 6. Security Considerations ................................... 15 + 7. IANA Considerations ....................................... 16 + 8. Acknowledgements .......................................... 16 + 9. Intellectual Property Considerations ...................... 16 + 10. Normative References ..................................... 16 + 11. Informational References ................................. 17 + 12. Authors' Addresses ....................................... 18 + 13. Full Copyright Statement ................................. 19 1. Introduction The Traffic Engineering Working Group has developed requirements for inter-area and inter-AS MPLS Traffic Engineering in [INTER-AREA] and [INTER-AS]. Various proposals have subsequently been made to address some or all of these requirements through extensions to the RSVP-TE and IGP (ISIS, OSPF) protocols and procedures. @@ -110,22 +110,25 @@ This document introduces the techniques for establishing TE LSPs across multiple domains. The functional components of these techniques are separated into the 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, 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 - engineering in packet and non-packet environments. + Engineering' is used equally to apply to MPLS and GMPLS traffic. + 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 collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems. However, domains of computational responsibility may also exist as sub-domains of areas or ASs. Wholly or partially overlapping domains are not within the scope of this document. 1.1. Nested Domains @@ -414,21 +417,21 @@ In this way an end-to-end path may be computed using the full network capabilities, but confidentiality between domains may be preserved. Optionally, the PCE(s) may compute the entire path at the first request and hold it in storage for subsequent requests, or it may recompute the best path on each request or at regular intervals. It may be the case that the centralized PCE or the collaboration between PCEs may define a trust relationship greater than that 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 domain. Each LSR within a domain that wishes to derive a path across the domain may consult its local PCE. This mechanism could be used for all path computations within the domain, or specifically limited to computations for LSPs that will leave the domain where external connectivity information can then be restricted to just the PCE. @@ -445,20 +448,24 @@ abstraction / summarization of routing information. 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 requirements documents and applicability statements. Note, however, that the meaning of certain computation metrics may differ between domains (see section 5.6). 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 make certain demands upon the distribution of reachability information and the TE capabilities of nodes and links within domains as well as the TE connectivity across domains. Currently, TE information is distributed within domains by additions to IGPs [RFC3630], [RFC3784]. 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), @@ -467,21 +474,21 @@ This would facilitate better path computation and reduce TE-related crankbacks on these links. Where a domain is a subset of an IGP area, filtering of TE information may be applied at the domain boundary. This filtering may be one way, or two way. 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 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 example, an ingress LSR) obtains the topology and TE information of not just its own domain, but other domains as well. This information may be subject to filtering applied by the advertising domain (for example, the information may be limited to FAs across other domains, or the information may be aggregated or abstracted). Where any cross-domain reachability and TE information needs to be advertised, consideration must be given to TE extensions to BGP, and @@ -518,31 +525,41 @@ Alternatively, re-optimization may involve a change in route across several domains or might involve a choice of different transit domains. 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 section 3, and this will influence whether the whole or part of the path is re-optimized. The trigger for path computation and re-optimization may be an - operator request, a timer, or information about a change in - availability of network resources. This trigger MUST be applied to - the point in the network that requests re-computation and controls - re-optimization and may require additional signaling. + operator request, a timer, information about a change in + availability of network resources, or a change in operational + parameters (for example bandwidth) of an LSP. This trigger MUST be + 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 (i.e. not simply within protection domains - see section 5.5) the point of calculation for re-optimization (whether it is PCE, ingress, or domain entry point) needs to know all such paths before attempting 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 When an inter-domain LSP setup fails in some domain other than the first, various options are available for reporting and retrying the LSP. In the first instance, a retry may be attempted within the domain that contains the failure. That retry may be attempted by nodes wholly within the domain, or the failure may be referred back to the LSR at the domain boundary. @@ -692,23 +709,23 @@ 5.8. Inter-domain OAM Some elements of OAM may be intentionally confined within a domain. Others (such as end-to-end liveness and connectivity testing) clearly need to span the entire multi-domain TE LSP. Where issues of confidentiality are strong, collaboration between PCEs or domain boundary nodes might be required in order to provide end-to-end OAM. The different signaling mechanisms described above may need - refinements to [LSPPING], [BFD-MPLS] or the use of [TUNTRACE] to gain - full end-to-end visibility. These protocols should, however, be - considered in the light of confidentiality requirements. + refinements to [LSPPING], and [BFD-MPLS], etc., to gain full + end-to-end visibility. These protocols should, however, be considered + in the light of confidentiality requirements. Route recording is a commonly used feature of signaling that provides OAM information about the path of an established LSP. When an LSP traverses a domain boundary, the border node may remove or aggregate some of the recorded information for confidentiality or other policy reasons. 5.9. Point-to-Multipoint Inter-domain point-to-multipoint (P2MP) requirements are explicitly @@ -790,48 +807,28 @@ Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 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 [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering Extensions to OSPF Version 2", RFC 3630, September 2003 [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", RFC 3784, June 2004. + [ATTRIB] A. Farrel, D. Papadimitriou, JP. Vasseur, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE", draft-ietf-mpls-rsvpte-attributes, work in progress. [BFD-MPLS] R. Aggarwal and K. Kompella, "BFD For MPLS LSPs", work in progress. [CRANKBACK] Farrel, A., et al., "Crankback Signaling Extensions for MPLS Signaling", draft-ietf-ccamp-crankback, @@ -842,39 +839,56 @@ progress. [FRR] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute, 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. + [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 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 Model", draft-ietf-ccamp-gmpls-overlay, work in 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, A., "GMPLS Based Segment Recovery", draft-ietf-ccamp-gmpls-segment-recovery, work in progress. - [TUNTRACE] Bonica, R., et al., "Generic Tunnel Tracing Protocol - (GTTP) Specification", draft-ietf-ccamp-tunproto, - work in progress. + [STITCH] Ayyangar, A., and Vasseur, JP., "LSP Stitching with + Generalized MPLS TE", + draft-ietf-ccamp-lsp-stitching, work in progress. 12. Authors' Addresses Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk Jean-Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road