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/