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/ |