--- 1/draft-ietf-ccamp-gmpls-mln-reqs-09.txt 2008-05-12 21:12:17.000000000 +0200 +++ 2/draft-ietf-ccamp-gmpls-mln-reqs-10.txt 2008-05-12 21:12:17.000000000 +0200 @@ -1,19 +1,20 @@ +
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) Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) - draft-ietf-ccamp-gmpls-mln-reqs-09.txt + draft-ietf-ccamp-gmpls-mln-reqs-10.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 @@ -25,21 +26,21 @@ documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html - This Internet-Draft will expire in April 2008. + This Internet-Draft will expire in May 2008. Abstract Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi- layered network of either a single switching technology or multiple @@ -77,30 +78,31 @@ 5.2. Advertisement of the Available Adjustment Resource........14 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 - 6. Security Considerations.....................................21 - 7. IANA Considerations.........................................21 - 8. Acknowledgements............................................21 - 9. References..................................................21 - 9.1. Normative Reference.......................................21 - 9.2. Informative References....................................22 - 10. Authors' Addresses.........................................23 - 11. Contributors' Addresses....................................24 - 12. Intellectual Property Considerations.......................24 - 13. Full Copyright Statement...................................25 + 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 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 @@ -983,27 +985,78 @@ When a lower layer LSP is established for use as a data link by a higher layer, the LSP may be verified for correct connectivity and data integrity before it is made available for use. Such mechanisms are data technology-specific and are beyond the scope of this document, but the GMPLS protocols SHOULD provide mechanisms for the coordination of data link verification. 5.10. Management + A MRN/MLN requires management capabilities. Operators need to have + the same level of control and management for switches and links in + the network that they would have in a single layer or single region + network. + + We can consider two different operational models: (1) Per-layer + management entities, (2) Cross-layer management entities. + + Regarding per-layer management entities, it is possible for the MLN + to be managed entirely as separate layers although that somewhat + defeats the objective of defining a single multi-layer network. In + this case, separate management systems would be operated for each + layer, and those systems would be unaware of the fact that the layers + were closely coupled in the control plane. In such a deployment, as + LSPs were automatically set up as the result of control plane + requests from other layers (for example, triggered signaling), the + management applications would need to register the creation of the + new LSPs and the depletion of network resources. Emphasis would be + placed on the layer boundary nodes to report the activity to the + management applications. + + A more likely scenario is to apply a closer coupling of layer + management systems with cross-layer management entities. This might + be achieved through a unified management system capable of operating + multiple layers, or by a meta-management system that coordinates the + operation of separate management systems each responsible for + individual layers. The former case might only be possible with the + development of new management systems, while the latter is feasible + through the coordination of existing network management tools. + + Note that when a layer boundary also forms an administrative boundary + it is highly unlikely that there will be unified multi-layer + management. In this case, the layers will be separately managed by + the separate administrative entities, but there may be some "leakage" + of information between the administrations in order to facilitate the + operation of the MLN. For example, the management system in the lower + layer network might automatically issue reports on resource + availability (coincident with TE routing information), and alarm + events. + + This discussion comes close to an examination of how a VNT might be + managed and operated. As noted in Section 5.8, issues of how to + design and manage a VNT are out of scope for this document, but it + should be understood, that the VNT is a client layer construct built + from server layer resources. This means that the operation of a VNT + is a collaborative activity between layers. This activity is possible + even if the layers are from separate administrations, but in this + case the activity may also have commercial implications. + 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. Multi-layer protocol solutions SHOULD be manageable - through MIB modules. A further MIB module to coordinate multiple - network layers may be produced. + 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. 6. Security Considerations