draft-ietf-ccamp-gmpls-mln-reqs-10.txt   draft-ietf-ccamp-gmpls-mln-reqs-11.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) Created: May 28, 2008 Martin Vigoureux (Alcatel-Lucent)
Deborah Brungard (AT&T) Expires: November 28, 2008 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-10.txt draft-ietf-ccamp-gmpls-mln-reqs-11.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 2, line 45 skipping to change at page 2, line 45
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
5.10. Management...............................................20 5.10. Management...............................................20
6. Security Considerations.....................................22 6. Security Considerations.....................................23
7. IANA Considerations.........................................22 7. IANA Considerations.........................................23
8. Acknowledgements............................................22 8. Acknowledgements............................................23
9. References..................................................22 9. References..................................................23
9.1. Normative Reference.......................................22 9.1. Normative Reference.......................................23
9.2. Informative References....................................23 9.2. Informative References....................................24
10. Authors' Addresses.........................................24 10. Authors' Addresses.........................................25
11. Contributors' Addresses....................................25 11. Contributors' Addresses....................................26
12. Intellectual Property Considerations.......................25 12. Intellectual Property Considerations.......................26
13. Full Copyright Statement...................................26 13. Full Copyright Statement...................................27
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 22, line 7 skipping to change at page 22, line 7
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 that could be developed. Multi-layer protocol solutions MIB module that could be developed. Multi-layer protocol solutions
(that is solutions where a single control plane instance operates in (that is solutions where a single control plane instance operates in
more than one layer) SHOULD be manageable through MIB modules. A more than one layer) SHOULD be manageable through MIB modules. A
further MIB module to coordinate multiple network layers with this further MIB module to coordinate multiple network layers with this
control plane MIB module may be produced. 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 all networks.
Protocol solutions for individual network layers SHOULD include
mechanisms for OAM or to make use of OAM features inherent in the OAM requirements for GMPLS networks are described in [GMPLS-OAM].
physical media of the layers. Multi-layer protocol solutions SHOULD That document points out that protocol solutions for individual
provide mechanisms to coordinate OAM mechanisms operating in each network layers should include mechanisms for OAM or to make use of
layer. 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 6. Security Considerations
The MLN/MRN architecture does not introduce any new security The MLN/MRN architecture does not introduce any new security
requirements over the general GMPLS architecture described in requirements over the general GMPLS architecture described in
[RFC3945]. Additional security considerations form MPLS and GMPLS [RFC3945]. Additional security considerations form MPLS and GMPLS
networks are described in [MPLS-SEC]. networks are described in [MPLS-SEC].
However, where the separate layers of a MLN/MRN network are However, where the separate layers of a MLN/MRN network are
operated as different administrative domains, additional security operated as different administrative domains, additional security
skipping to change at page 22, line 41 skipping to change at page 23, line 38
of the security issues that any protocol extensions introduce. of the security issues that any protocol extensions introduce.
7. IANA Considerations 7. IANA Considerations
This informational document makes no requests to IANA for action. This informational document makes no requests to IANA for action.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Adrian Farrel and the participants The authors would like to thank Adrian Farrel and the participants
of ITU-T Study Group 15 Question 14 for their careful review. The of ITU-T Study Group 15 Question 14 for their careful review. The
authors would like to thank the IESG review team for rigorous authors would like to thank the IESG review team for rigorous review:
review: special thanks to Tim Polk, Miguel Garcia, Jari Arkko, and special thanks to Tim Polk, Miguel Garcia, Jari Arkko, Dan Romascanu,
Dan Romascanu. and Dave Ward.
9. References 9. References
9.1. Normative Reference 9.1. Normative Reference
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3945] E. Mannie (Editor), "Generalized Multi-Protocol Label [RFC3945] E. Mannie (Editor), "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004. Switching (GMPLS) Architecture", RFC 3945, October 2004.
skipping to change at page 24, line 6 skipping to change at page 24, line 52
Multiprotocol Label Switching (GMPLS) Traffic Multiprotocol Label Switching (GMPLS) Traffic
Engineering Management Information Base", RFC 4802, Engineering Management Information Base", RFC 4802,
February 2007. February 2007.
[RFC4803] Nadeau, T., Ed. and A. Farrel, Ed., "Generalized [RFC4803] Nadeau, T., Ed. and A. Farrel, Ed., "Generalized
Multiprotocol Label Switching (GMPLS) Label Switching Multiprotocol Label Switching (GMPLS) Label Switching
Router (LSR) Management Information Base", RFC 4803, Router (LSR) Management Information Base", RFC 4803,
February 2007. February 2007.
[RFC4847] T. Takeda (Editor), " Framework and Requirements for [RFC4847] T. Takeda (Editor), " Framework and Requirements for
Layer 1 Virtual Private Networks", RFC 4847, April Layer 1 Virtual Private Networks", RFC 4847, April 2007.
2007.
[RFC4972] Vasseur, JP., Le Roux, JL., et al., "Routing [RFC4972] Vasseur, JP., Le Roux, JL., et al., "Routing
Extensions for Discovery of Multiprotocol (MPLS) Extensions for Discovery of Multiprotocol (MPLS)
Label Switch Router (LSR) Traffic Engineering (TE) Label Switch Router (LSR) Traffic Engineering (TE)
Mesh Membership", RFC 4972, July 2007. 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 10. Authors' Addresses
Kohei Shiomoto Kohei Shiomoto
NTT Network Service Systems Laboratories NTT Network Service Systems Laboratories
3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan
Email: shiomoto.kohei@lab.ntt.co.jp Email: shiomoto.kohei@lab.ntt.co.jp
Dimitri Papadimitriou Dimitri Papadimitriou
Alcatel-Lucent Alcatel-Lucent
Copernicuslaan 50, Copernicuslaan 50,
 End of changes. 8 change blocks. 
25 lines changed or deleted 77 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/