--- 1/draft-ietf-ccamp-gmpls-mln-reqs-10.txt 2008-05-28 12:13:41.000000000 +0200 +++ 2/draft-ietf-ccamp-gmpls-mln-reqs-11.txt 2008-05-28 12:13:41.000000000 +0200 @@ -1,20 +1,21 @@ -
+ Network Working Group Kohei Shiomoto (NTT) Internet-Draft Dimitri Papadimitriou (Alcatel-Lucent) Intended Status: Informational Jean-Louis Le Roux (France Telecom) - Martin Vigoureux (Alcatel-Lucent) - Deborah Brungard (AT&T) +Created: May 28, 2008 Martin Vigoureux (Alcatel-Lucent) +Expires: November 28, 2008 Deborah Brungard (AT&T) + Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) - draft-ietf-ccamp-gmpls-mln-reqs-10.txt + draft-ietf-ccamp-gmpls-mln-reqs-11.txt Status of this Memo 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 @@ -79,30 +80,30 @@ 5.3. Scalability...............................................15 5.4. Stability.................................................16 5.5. Disruption Minimization...................................16 5.6. LSP Attribute Inheritance.................................16 5.7. Computing Paths With and Without Nested Signaling.........17 5.8. LSP Resource Utilization..................................18 5.8.1. FA-LSP Release and Setup................................18 5.8.2. Virtual TE-Links........................................19 5.9. Verification of the LSPs..................................20 5.10. Management...............................................20 - 6. Security Considerations.....................................22 - 7. IANA Considerations.........................................22 - 8. Acknowledgements............................................22 - 9. References..................................................22 - 9.1. Normative Reference.......................................22 - 9.2. Informative References....................................23 - 10. Authors' Addresses.........................................24 - 11. Contributors' Addresses....................................25 - 12. Intellectual Property Considerations.......................25 - 13. Full Copyright Statement...................................26 + 6. Security Considerations.....................................23 + 7. IANA Considerations.........................................23 + 8. Acknowledgements............................................23 + 9. References..................................................23 + 9.1. Normative Reference.......................................23 + 9.2. Informative References....................................24 + 10. Authors' Addresses.........................................25 + 11. Contributors' Addresses....................................26 + 12. Intellectual Property Considerations.......................26 + 13. Full Copyright Statement...................................27 1. Introduction Generalized MPLS (GMPLS) extends MPLS to handle multiple switching technologies: packet switching, layer-2 switching, TDM switching, wavelength switching, and fiber switching (see [RFC3945]). The Interface Switching Capability (ISC) concept is introduced for these switching technologies and is designated as follows: PSC (packet switch capable), L2SC (Layer-2 switch capable), TDM (Time Division Multiplex capable), LSC (lambda switch capable), and FSC @@ -1044,26 +1045,73 @@ MIB modules exist for the modeling and management of GMPLS networks [RFC4802], [RFC4803]. Some deployments of GMPLS networks may choose to use MIB modules to operate individual network layers. In these cases, operators may desire to coordinate layers through a further MIB module that could be developed. Multi-layer protocol solutions (that is solutions where a single control plane instance operates in more than one layer) SHOULD be manageable through MIB modules. A further MIB module to coordinate multiple network layers with this control plane MIB module may be produced. - OAM tools are important to the successful deployment of networks. - Protocol solutions for individual network layers SHOULD include - mechanisms for OAM or to make use of OAM features inherent in the - physical media of the layers. Multi-layer protocol solutions SHOULD - provide mechanisms to coordinate OAM mechanisms operating in each - layer. + OAM tools are important to the successful deployment of all networks. + + OAM requirements for GMPLS networks are described in [GMPLS-OAM]. + That document points out that protocol solutions for individual + network layers should include mechanisms for OAM or to make use of + OAM features inherent in the physical media of the layers. Further + discussion of individual layer OAM is out of scope of this document. + + When operating OAM in a MLN, consideration must be given to how to + provide OAM for end-to-end LSPs that cross domain boundaries and how + to coordinate errors and alarms detected in a server layer that need + to be reported to the client layer. These operational choices MUST be + left open to the service provider and so MLN protocol solutions MUST + include the following features: + + - Within the context and technology capabilities of the highest + technology layer of an LSP (i.e., the technology layer of the first + hop), it MUST be possible to enable end-to-end OAM on a MLN LSP. + This function appears to the ingress LSP as normal LSP-based OAM + [GMPLS-OAM], but at layer boundaries, depending on the technique + used to span the lower layers, client layer OAM operations may need + to mapped to server layer OAM operations. Most such requirements + are highly dependent on the OAM facilities of the data plane + technologies of client and server layers. However, control plane + mechanisms used in the client layer per [GMPLS-OAM] MUST map and + enable OAM in the server layer. + + - OAM operation enabled per [GMPLS-OAM] in a client layer for an LSP + MUST operate for that LSP along its entire length. This means that + if an LSP crosses a domain of a lower layer technology, the client + layer OAM operation must operate seamlessly within the client layer + at both ends of the client layer LSP. + + - OAM function operating within a server layer MUST be controllable + from the client layer such that the server layer LSP(s) that + support a client layer LSP have OAM enabled at the request of the + client layer. Such control SHOULD be subject to policy at the layer + boundary just as automatic provisioning and LSP requests to the + server layer are subject to policy. + + - The status including errors and alarms applicable to a server layer + LSP MUST be available to the client layer. This information SHOULD + be configurable to be automatically notified to the client layer at + the layer boundary and SHOULD be subject to policy so that the + server layer may filter or hide information supplied to the client + layer. Furthermore, the client layer SHOULD be able to select to + not receive any or all such information. + + Note that the interface between layers lies within network nodes and + is, therefore, not necessarily the subject of a protocol + specification. Implementations MAY use standardized techniques (such + as MIB modules) to convey status information (such as errors and + alarms) between layers, but that is out of scope for this document. 6. Security Considerations The MLN/MRN architecture does not introduce any new security requirements over the general GMPLS architecture described in [RFC3945]. Additional security considerations form MPLS and GMPLS networks are described in [MPLS-SEC]. However, where the separate layers of a MLN/MRN network are operated as different administrative domains, additional security @@ -1078,23 +1126,23 @@ of the security issues that any protocol extensions introduce. 7. IANA Considerations This informational document makes no requests to IANA for action. 8. Acknowledgements The authors would like to thank Adrian Farrel and the participants of ITU-T Study Group 15 Question 14 for their careful review. The - authors would like to thank the IESG review team for rigorous - review: special thanks to Tim Polk, Miguel Garcia, Jari Arkko, and - Dan Romascanu. + authors would like to thank the IESG review team for rigorous review: + special thanks to Tim Polk, Miguel Garcia, Jari Arkko, Dan Romascanu, + and Dave Ward. 9. References 9.1. Normative Reference [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3945] E. Mannie (Editor), "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. @@ -1143,28 +1191,32 @@ Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007. [RFC4803] Nadeau, T., Ed. and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base", RFC 4803, February 2007. [RFC4847] T. Takeda (Editor), " Framework and Requirements for - Layer 1 Virtual Private Networks", RFC 4847, April - 2007. + Layer 1 Virtual Private Networks", RFC 4847, April 2007. [RFC4972] Vasseur, JP., Le Roux, JL., et al., "Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership", RFC 4972, July 2007. + [GMPLS-OAM] Nadeau, T., Otani, T. Brungard, D., and Farrel, A., "OAM + Requirements for Generalized Multi-Protocol Label + Switching (GMPLS) Networks", draft-ietf-ccamp-gmpls-oam- + requirements, work in progress. + 10. Authors' Addresses Kohei Shiomoto NTT Network Service Systems Laboratories 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: shiomoto.kohei@lab.ntt.co.jp Dimitri Papadimitriou Alcatel-Lucent Copernicuslaan 50,