rfc9270v1.txt		rfc9270.txt
	skipping to change at line 214 ¶		skipping to change at line 214 ¶
	\ /		\ /
	E---F---G		E---F---G
	/ \		/ \
	H---I---J---K		H---I---J---K
	Figure 1: An Example of an SMP Topology		Figure 1: An Example of an SMP Topology
	The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by the		The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by the
	protecting LSPs [A,E,F,G,D] and [H,E,F,G,K], respectively. Per RFC		protecting LSPs [A,E,F,G,D] and [H,E,F,G,K], respectively. Per RFC
	3209 [RFC3209], in order to achieve resource sharing during the		3209 [RFC3209], in order to achieve resource sharing during the
	signaling of these protecting LSPs, they MUST have the same Tunnel		signaling of these protecting LSPs, they have the same Tunnel
	Endpoint Address (as part of their SESSION object). However, these		Endpoint Address (as part of their SESSION object). However, these
	addresses are not the same in this example. Similar to SMR, this		addresses are not the same in this example. Similar to SMR, this
	document defines a new LSP Protection Type of the secondary LSP as		document defines a new LSP Protection Type of the secondary LSP as
	"Shared Mesh Protection" (see Section 6.1) to allow resource sharing		"Shared Mesh Protection" (see Section 6.1) to allow resource sharing
	along nodes E, F, and G. Examples of shared resources include the		along nodes E, F, and G. Examples of shared resources include the
	capacity of a link and the cross-connects in a node. In this case,		capacity of a link and the cross-connects in a node. In this case,
	the protecting LSPs are not merged (which is useful, since the paths		the protecting LSPs are not merged (which is useful, since the paths
	diverge at G), but the resources along E, F, and G can be shared.		diverge at G), but the resources along E, F, and G can be shared.
	When a failure, such as Signal Fail (SF) or Signal Degrade (SD),		When a failure, such as Signal Fail (SF) or Signal Degrade (SD),
	skipping to change at line 306 ¶		skipping to change at line 306 ¶
	The PROTECTION object (see [RFC4872]) is included in the Path message		The PROTECTION object (see [RFC4872]) is included in the Path message
	during signaling of the primary working LSPs, with the LSP Protection		during signaling of the primary working LSPs, with the LSP Protection
	Type value set to "Shared Mesh Protection".		Type value set to "Shared Mesh Protection".
	Primary working LSPs are signaled by setting in the PROTECTION object		Primary working LSPs are signaled by setting in the PROTECTION object
	the S bit to 0, the P bit to 0, and the N bit to 1; and setting in		the S bit to 0, the P bit to 0, and the N bit to 1; and setting in
	the ASSOCIATION object the Association ID to the associated secondary		the ASSOCIATION object the Association ID to the associated secondary
	protecting LSP_ID.		protecting LSP_ID.
	Note: The N bit is set to indicate that the protection switching		| Note: The N bit is set to indicate that the protection
	signaling is done via the data plane.		| switching signaling is done via the data plane.
	5.3. Signaling Secondary LSPs		5.3. Signaling Secondary LSPs
	The PROTECTION object (see [RFC4872]) is included in the Path message		The PROTECTION object (see [RFC4872]) is included in the Path message
	during signaling of the secondary protecting LSPs, with the LSP		during signaling of the secondary protecting LSPs, with the LSP
	Protection Type value set to "Shared Mesh Protection".		Protection Type value set to "Shared Mesh Protection".
	Secondary protecting LSPs are signaled by setting in the PROTECTION		Secondary protecting LSPs are signaled by setting in the PROTECTION
	object the S bit, the P bit, and the N bit to 1; and setting in the		object the S bit, the P bit, and the N bit to 1; and setting in the
	ASSOCIATION object the Association ID to the associated primary		ASSOCIATION object the Association ID to the associated primary
	skipping to change at line 367 ¶		skipping to change at line 367 ¶
	message, the priority value in the Preemption Priority field MUST be		message, the priority value in the Preemption Priority field MUST be
	stored for that protecting LSP. When resource competition among		stored for that protecting LSP. When resource competition among
	multiple protecting LSPs occurs, the APS protocol will use their		multiple protecting LSPs occurs, the APS protocol will use their
	priority values to resolve this competition. A lower value has a		priority values to resolve this competition. A lower value has a
	higher priority.		higher priority.
	In SMP, a preempted LSP MUST NOT be terminated even after its		In SMP, a preempted LSP MUST NOT be terminated even after its
	resources have been deallocated. Once the working LSP and the		resources have been deallocated. Once the working LSP and the
	protecting LSP are configured or preconfigured, the end node MUST		protecting LSP are configured or preconfigured, the end node MUST
	keep refreshing both working and protecting LSPs, regardless of		keep refreshing both working and protecting LSPs, regardless of
	failure or preempted situation.		failure or preemption status.
	5.5. Availability of Shared Resources: The Notify Message		5.5. Availability of Shared Resources: The Notify Message
	When a lower-priority protecting LSP is preempted, the intermediate		When a lower-priority protecting LSP is preempted, the intermediate
	node that performed the preemption MUST send a Notify message with		node that performed the preemption MUST send a Notify message with
	error code "Notify Error" (25) (see [RFC4872]) and error sub-code		error code "Notify Error" (25) (see [RFC4872]) and error sub-code
	"Shared resources unavailable" (17) to the end nodes of that		"Shared resources unavailable" (17) to the end nodes of that
	protecting LSP. Upon receipt of this Notify message, the end node		protecting LSP. Upon receipt of this Notify message, the end node
	MUST stop sending and selecting traffic to/from its protecting LSP		MUST stop sending and selecting traffic to/from its protecting LSP
	and try switching the traffic to another protecting LSP, if		and try switching the traffic to another protecting LSP, if
	skipping to change at line 407 ¶		skipping to change at line 407 ¶
	priority protecting LSPs that have been preempted and/or all the end		priority protecting LSPs that have been preempted and/or all the end
	nodes of the protecting LSPs that have lower SMP preemption		nodes of the protecting LSPs that have lower SMP preemption
	priorities than the one that does not need the shared resources		priorities than the one that does not need the shared resources
	anymore. Upon receipt of this Notify message, the end node is		anymore. Upon receipt of this Notify message, the end node is
	allowed to reinitiate the protection switching operation as described		allowed to reinitiate the protection switching operation as described
	in Section 4, if it still needs the protection resource.		in Section 4, if it still needs the protection resource.
	5.6. SMP APS Configuration		5.6. SMP APS Configuration
	SMP relies on APS protocol messages being exchanged between the nodes		SMP relies on APS protocol messages being exchanged between the nodes
	along the path to activate an SMP protecting LSP.		along the path to activate a protecting LSP.
	In order to allow the exchange of APS protocol messages, an APS		In order to allow the exchange of APS protocol messages, an APS
	channel has to be configured between adjacent nodes along the path of		channel has to be configured between adjacent nodes along the path of
	the SMP protecting LSP. This is done by means other than GMPLS		the protecting LSP. This is done by means other than GMPLS
	signaling, before any SMP protecting LSP has been set up. Therefore,		signaling, before any protecting LSP has been set up. Therefore,
	there are likely additional requirements for APS configuration that		there are likely additional requirements for APS configuration that
	are outside the scope of this document.		are outside the scope of this document.
	Depending on the APS protocol message format, the APS protocol may		Depending on the APS protocol message format, the APS protocol may
	use different identifiers than GMPLS signaling to identify the SMP		use different identifiers than GMPLS signaling to identify the
	protecting LSP.		protecting LSP.
	Since the APS protocol is left for further study per [G808.3], it can		Since the APS protocol is left for further study per [G808.3], it can
	be assumed that the APS message format and identifiers are technology		be assumed that the APS message format and identifiers are technology
	specific and/or vendor specific. Therefore, additional requirements		specific and/or vendor specific. Therefore, additional requirements
	for APS configuration are outside the scope of this document.		for APS configuration are outside the scope of this document.
	6. Updates to PROTECTION Object		6. Updates to PROTECTION Object
	GMPLS extension requirements for SMP introduce several updates to the		GMPLS extension requirements for SMP introduce several updates to the
	skipping to change at line 466 ¶		skipping to change at line 466 ¶
	Type Flag is set to 0x04 (1:N Protection with Extra-Traffic), 0x08		Type Flag is set to 0x04 (1:N Protection with Extra-Traffic), 0x08
	(1+1 Unidirectional Protection), 0x10 (1+1 Bidirectional		(1+1 Unidirectional Protection), 0x10 (1+1 Bidirectional
	Protection), or 0x20 (Shared Mesh Protection). The N bit MUST be		Protection), or 0x20 (Shared Mesh Protection). The N bit MUST be
	set to 0 in any other case. If 0x20 (SMP), the N bit MUST be set		set to 0 in any other case. If 0x20 (SMP), the N bit MUST be set
	to 1.		to 1.
	Operational (O): 1 bit		Operational (O): 1 bit
	When set to 1, this bit indicates that the protecting LSP is		When set to 1, this bit indicates that the protecting LSP is
	carrying traffic after protection switching. The O bit is only		carrying traffic after protection switching. The O bit is only
	applicable when the P bit is set to 1, and the LSP Protection Type		applicable when (1) the P bit is set to 1 and (2) the LSP
	Flag is set to 0x04 (1:N Protection with Extra-Traffic), 0x08 (1+1		Protection Type Flag is set to 0x04 (1:N Protection with Extra-
	Unidirectional Protection), 0x10 (1+1 Bidirectional Protection),		Traffic), 0x08 (1+1 Unidirectional Protection), 0x10 (1+1
	or 0x20 (Shared Mesh Protection). The O bit MUST be set to 0 in		Bidirectional Protection), or 0x20 (Shared Mesh Protection). The
	any other case.		O bit MUST be set to 0 in any other case.
	6.3. Preemption Priority		6.3. Preemption Priority
	[RFC4872] reserved a 32-bit field in the PROTECTION object header.		[RFC4872] reserved a 32-bit field in the PROTECTION object header.
	Subsequently, [RFC4873] allocated several bits from that field and		Subsequently, [RFC4873] allocated several bits from that field and
	left the remainder of the bits reserved. This specification further		left the remainder of the bits reserved. This specification further
	allocates the Preemption Priority field from the remaining formerly		allocates the Preemption Priority field from the remaining formerly
	reserved bits. The 32-bit field in the PROTECTION object as defined		reserved bits. The 32-bit field in the PROTECTION object as defined
	in [RFC4872] and modified by [RFC4873] is updated by this document as		in [RFC4872] and modified by [RFC4873] is updated by this document as
	follows:		follows:
	skipping to change at line 555 ¶		skipping to change at line 555 ¶
	G.808.3, October 2012,		G.808.3, October 2012,
	<https://www.itu.int/rec/T-REC-G.808.3>.		<https://www.itu.int/rec/T-REC-G.808.3>.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP		and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,		Tunnels", DOI 10.17487/RFC3209, RFC 3209, December 2001,
	<https://www.rfc-editor.org/info/rfc3209>.		<https://www.rfc-editor.org/info/rfc3209>.
	[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label		[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
	Switching (GMPLS) Signaling Resource ReserVation Protocol-		(GMPLS) Signaling Resource ReserVation Protocol-Traffic
	Traffic Engineering (RSVP-TE) Extensions", RFC 3473,		Engineering (RSVP-TE) Extensions", DOI 10.17487/RFC3473,
	DOI 10.17487/RFC3473, January 2003,		RFC 3473, January 2003,
	<https://www.rfc-editor.org/info/rfc3473>.		<https://www.rfc-editor.org/info/rfc3473>.
	[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou,		[RFC4426] Lang, J., Rajagopalan, B., and D. Papadimitriou,
	Ed., "Generalized Multi-Protocol Label Switching (GMPLS)		"Generalized Multi-Protocol Label Switching (GMPLS)
	Recovery Functional Specification", RFC 4426,		Recovery Functional Specification", DOI 10.17487/RFC4426,
	DOI 10.17487/RFC4426, March 2006,		RFC 4426, March 2006,
	<https://www.rfc-editor.org/info/rfc4426>.		<https://www.rfc-editor.org/info/rfc4426>.
	[RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou,		[RFC4872] Lang, J P., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
	Ed., "RSVP-TE Extensions in Support of End-to-End		Extensions in Support of End-to-End Generalized Multi-
	Generalized Multi-Protocol Label Switching (GMPLS)		Protocol Label Switching (GMPLS) Recovery", RFC 4872,
	Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,		DOI 10.17487/RFC4872, May 2007,
	<https://www.rfc-editor.org/info/rfc4872>.		<https://www.rfc-editor.org/info/rfc4872>.
	[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,		[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
	"GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,		"GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
	May 2007, <https://www.rfc-editor.org/info/rfc4873>.		May 2007, <https://www.rfc-editor.org/info/rfc4873>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	9.2. Informative References		9.2. Informative References
	[G873.3] International Telecommunication Union, "Optical transport		[G873.3] International Telecommunication Union, "Optical transport
	network - Shared mesh protection", ITU-T Recommendation		network - Shared mesh protection", ITU-T Recommendation
	G.873.3, September 2017,		G.873.3, September 2017,
	<https://www.itu.int/rec/T-REC-G.873.3-201709-I/en>.		<https://www.itu.int/rec/T-REC-G.873.3-201709-I/en>.
	[RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport		[RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS-
	Profile (MPLS-TP) Survivability Framework", RFC 6372,		TP) Survivability Framework", DOI 10.17487/RFC6372,
	DOI 10.17487/RFC6372, September 2011,		RFC 6372, September 2011,
	<https://www.rfc-editor.org/info/rfc6372>.		<https://www.rfc-editor.org/info/rfc6372>.
	[RFC7412] Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., and G.		[RFC7412] Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., and G.
	Mirsky, "Requirements for MPLS Transport Profile (MPLS-TP)		Mirsky, "Requirements for MPLS Transport Profile (MPLS-TP)
	Shared Mesh Protection", RFC 7412, DOI 10.17487/RFC7412,		Shared Mesh Protection", DOI 10.17487/RFC7412, RFC 7412,
	December 2014, <https://www.rfc-editor.org/info/rfc7412>.		December 2014, <https://www.rfc-editor.org/info/rfc7412>.
	[RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,		[RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
	"Common YANG Data Types for Traffic Engineering",		"Common YANG Data Types for Traffic Engineering",
	RFC 8776, DOI 10.17487/RFC8776, June 2020,		DOI 10.17487/RFC8776, RFC 8776, June 2020,
	<https://www.rfc-editor.org/info/rfc8776>.		<https://www.rfc-editor.org/info/rfc8776>.
	[YANG-TE] Saad, T., Gandhi, R., Liu, X., Beeram, V.P., Bryskin, I.,		[YANG-TE] Saad, T., Gandhi, R., Liu, X., Beeram, V.P., Bryskin, I.,
	and O. Gonzalez de Dios, "A YANG Data Model for Traffic		and O. Gonzalez de Dios, "A YANG Data Model for Traffic
	Engineering Tunnels, Label Switched Paths and Interfaces",		Engineering Tunnels, Label Switched Paths and Interfaces",
	Work in Progress, Internet-Draft, draft-ietf-teas-yang-te-		Work in Progress, Internet-Draft, draft-ietf-teas-yang-te-
	29, 7 February 2022,		29, 7 February 2022,
	<https://datatracker.ietf.org/doc/html/draft-ietf-teas-		<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
	yang-te-29>.		yang-te-29>.
End of changes. 14 change blocks.
	31 lines changed or deleted		31 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/