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/