draft-ietf-ccamp-gmpls-mln-reqs-09.txt | draft-ietf-ccamp-gmpls-mln-reqs-10.txt | |||
---|---|---|---|---|
<div class="moz-text-flowed" style="font-family: -moz-fixed"> | ||||
Network Working Group Kohei Shiomoto (NTT) | Network Working Group Kohei Shiomoto (NTT) | |||
Internet-Draft Dimitri Papadimitriou (Alcatel-Lucent) | Internet-Draft Dimitri Papadimitriou (Alcatel-Lucent) | |||
Intended Status: Informational Jean-Louis Le Roux (France Telecom) | Intended Status: Informational Jean-Louis Le Roux (France Telecom) | |||
Martin Vigoureux (Alcatel-Lucent) | Martin Vigoureux (Alcatel-Lucent) | |||
Deborah Brungard (AT&T) | Deborah Brungard (AT&T) | |||
Requirements for GMPLS-Based Multi-Region and | Requirements for GMPLS-Based Multi-Region and | |||
Multi-Layer Networks (MRN/MLN) | 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 | 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 page 1, line 36 | skipping to change at page 1, line 37 | |||
documents at any time. It is inappropriate to use Internet-Drafts | documents at any time. It is inappropriate to use Internet-Drafts | |||
as reference material or to cite them other than as "work in | as reference material or to cite them other than as "work in | |||
progress." | progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html | http://www.ietf.org/shadow.html | |||
This Internet-Draft will expire in April 2008. | This Internet-Draft will expire in May 2008. | |||
Abstract | Abstract | |||
Most of the initial efforts to utilize Generalized MPLS (GMPLS) | Most of the initial efforts to utilize Generalized MPLS (GMPLS) | |||
have been related to environments hosting devices with a single | have been related to environments hosting devices with a single | |||
switching capability. The complexity raised by the control of such | switching capability. The complexity raised by the control of such | |||
data planes is similar to that seen in classical IP/MPLS networks. | data planes is similar to that seen in classical IP/MPLS networks. | |||
By extending MPLS to support multiple switching technologies, GMPLS | By extending MPLS to support multiple switching technologies, GMPLS | |||
provides a comprehensive framework for the control of a multi- | provides a comprehensive framework for the control of a multi- | |||
layered network of either a single switching technology or multiple | layered network of either a single switching technology or multiple | |||
skipping to change at page 2, line 44 | skipping to change at page 2, line 44 | |||
5.2. Advertisement of the Available Adjustment Resource........14 | 5.2. Advertisement of the Available Adjustment Resource........14 | |||
5.3. Scalability...............................................15 | 5.3. Scalability...............................................15 | |||
5.4. Stability.................................................16 | 5.4. Stability.................................................16 | |||
5.5. Disruption Minimization...................................16 | 5.5. Disruption Minimization...................................16 | |||
5.6. LSP Attribute Inheritance.................................16 | 5.6. LSP Attribute Inheritance.................................16 | |||
5.7. Computing Paths With and Without Nested Signaling.........17 | 5.7. Computing Paths With and Without Nested Signaling.........17 | |||
5.8. LSP Resource Utilization..................................18 | 5.8. LSP Resource Utilization..................................18 | |||
5.8.1. FA-LSP Release and Setup................................18 | 5.8.1. FA-LSP Release and Setup................................18 | |||
5.8.2. Virtual TE-Links........................................19 | 5.8.2. Virtual TE-Links........................................19 | |||
5.9. Verification of the LSPs..................................20 | 5.9. Verification of the LSPs..................................20 | |||
6. Security Considerations.....................................21 | 5.10. Management...............................................20 | |||
7. IANA Considerations.........................................21 | 6. Security Considerations.....................................22 | |||
8. Acknowledgements............................................21 | 7. IANA Considerations.........................................22 | |||
9. References..................................................21 | 8. Acknowledgements............................................22 | |||
9.1. Normative Reference.......................................21 | 9. References..................................................22 | |||
9.2. Informative References....................................22 | 9.1. Normative Reference.......................................22 | |||
10. Authors' Addresses.........................................23 | 9.2. Informative References....................................23 | |||
11. Contributors' Addresses....................................24 | 10. Authors' Addresses.........................................24 | |||
12. Intellectual Property Considerations.......................24 | 11. Contributors' Addresses....................................25 | |||
13. Full Copyright Statement...................................25 | 12. Intellectual Property Considerations.......................25 | |||
13. Full Copyright Statement...................................26 | ||||
1. Introduction | 1. Introduction | |||
Generalized MPLS (GMPLS) extends MPLS to handle multiple switching | Generalized MPLS (GMPLS) extends MPLS to handle multiple switching | |||
technologies: packet switching, layer-2 switching, TDM switching, | technologies: packet switching, layer-2 switching, TDM switching, | |||
wavelength switching, and fiber switching (see [RFC3945]). The | wavelength switching, and fiber switching (see [RFC3945]). The | |||
Interface Switching Capability (ISC) concept is introduced for | Interface Switching Capability (ISC) concept is introduced for | |||
these switching technologies and is designated as follows: PSC | these switching technologies and is designated as follows: PSC | |||
(packet switch capable), L2SC (Layer-2 switch capable), TDM (Time | (packet switch capable), L2SC (Layer-2 switch capable), TDM (Time | |||
Division Multiplex capable), LSC (lambda switch capable), and FSC | Division Multiplex capable), LSC (lambda switch capable), and FSC | |||
skipping to change at page 20, line 48 | skipping to change at page 20, line 48 | |||
When a lower layer LSP is established for use as a data link by a | 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 | higher layer, the LSP may be verified for correct connectivity and | |||
data integrity before it is made available for use. Such mechanisms | data integrity before it is made available for use. Such mechanisms | |||
are data technology-specific and are beyond the scope of this | are data technology-specific and are beyond the scope of this | |||
document, but the GMPLS protocols SHOULD provide mechanisms for the | document, but the GMPLS protocols SHOULD provide mechanisms for the | |||
coordination of data link verification. | coordination of data link verification. | |||
5.10. Management | 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 | MIB modules exist for the modeling and management of GMPLS networks | |||
[RFC4802], [RFC4803]. Some deployments of GMPLS networks may choose | [RFC4802], [RFC4803]. Some deployments of GMPLS networks may choose | |||
to use MIB modules to operate individual network layers. In these | to use MIB modules to operate individual network layers. In these | |||
cases, operators may desire to coordinate layers through a further | cases, operators may desire to coordinate layers through a further | |||
MIB module. Multi-layer protocol solutions SHOULD be manageable | MIB module that could be developed. Multi-layer protocol solutions | |||
through MIB modules. A further MIB module to coordinate multiple | (that is solutions where a single control plane instance operates in | |||
network layers may be produced. | 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. | OAM tools are important to the successful deployment of networks. | |||
Protocol solutions for individual network layers SHOULD include | Protocol solutions for individual network layers SHOULD include | |||
mechanisms for OAM or to make use of OAM features inherent in the | mechanisms for OAM or to make use of OAM features inherent in the | |||
physical media of the layers. Multi-layer protocol solutions SHOULD | physical media of the layers. Multi-layer protocol solutions SHOULD | |||
provide mechanisms to coordinate OAM mechanisms operating in each | provide mechanisms to coordinate OAM mechanisms operating in each | |||
layer. | layer. | |||
6. Security Considerations | 6. Security Considerations | |||
End of changes. 6 change blocks. | ||||
15 lines changed or deleted | 68 lines changed or added | |||
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |