< draft-ietf-l2tpext-circuit-status-extensions-04.txt		draft-ietf-l2tpext-circuit-status-extensions-05.txt >
	Network Working Group N. McGill		Network Working Group N. McGill
	Internet-Draft C. Pignataro		Internet-Draft C. Pignataro
	Updates: 3931, 4349, 4454, 4591, Cisco Systems		Updates: 3931, 4349, 4454, 4591, Cisco Systems
	4719 (if approved) April 13, 2009		4719 (if approved) July 12, 2009
	Intended status: Standards Track		Intended status: Standards Track
	Expires: October 15, 2009		Expires: January 13, 2010
	L2TPv3 Extended Circuit Status Values		L2TPv3 Extended Circuit Status Values
	draft-ietf-l2tpext-circuit-status-extensions-04		draft-ietf-l2tpext-circuit-status-extensions-05
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and 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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in 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 on October 15, 2009.		This Internet-Draft will expire on January 13, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.		and restrictions with respect to this document.
	Abstract		Abstract
	This document defines additional Layer 2 Tunneling Protocol Version 3		This document defines additional Layer 2 Tunneling Protocol Version 3
	(L2TPv3) bit values to be used within the "Circuit Status" Attribute		(L2TPv3) bit values to be used within the "Circuit Status" Attribute
	Value Pair (AVP) to communicate more granular error states for		Value Pair (AVP) to communicate finer-grained error states for
	Attachment Circuits (ACs) and Pseudowires (PWs). It also generalizes		Attachment Circuits (ACs) and Pseudowires (PWs). It also generalizes
	the Active bit and deprecates the use of the New bit in the "Circuit		the Active bit and deprecates the use of the New bit in the "Circuit
	Status" AVP, updating RFC3931, RFC4349, RFC4454, RFC4591, and		Status" AVP, updating RFC3931, RFC4349, RFC4454, RFC4591, and
	RFC4719.		RFC4719.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Specification of Requirements . . . . . . . . . . . . . . 3		1.1. Specification of Requirements . . . . . . . . . . . . . . 3
	2. L2TPv3 Extended Circuit Status Values . . . . . . . . . . . . 3		2. L2TPv3 Extended Circuit Status Values . . . . . . . . . . . . 3
	3. Circuit Status Usage and Clarifications . . . . . . . . . . . 8		3. Circuit Status Usage and Clarifications . . . . . . . . . . . 8
	4. Updates to Existing RFCs . . . . . . . . . . . . . . . . . . . 8		4. Updates to Existing RFCs . . . . . . . . . . . . . . . . . . . 9
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 10		8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	8.2. Informative References . . . . . . . . . . . . . . . . . . 11		8.2. Informative References . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	Currently the L2TPv3 Circuit Status AVP [RFC3931] is able to convey		Currently the L2TPv3 Circuit Status AVP [RFC3931] is able to convey
	the UP/DOWN status of an access circuit. However, a finer		the UP/DOWN status of an access circuit. However, a finer
	granularity is often useful to determine the direction of the fault		granularity is often useful to determine the direction of the fault
	as has been added for MPLS-based pseudowires and used in the		as has been added for MPLS-based pseudowires and used in the
	pseudowire control protocol using LDP, see Section 3.5 of [RFC4446]		pseudowire control protocol using the Label Distribution Protocol
	and Section 5.4.2 of [RFC4447].		(LDP), see Section 3.5 of [RFC4446] and Section 5.4.2 of [RFC4447].
	Additionally, it is useful (in session-level redundancy scenarios) to		Additionally, it is useful (in session-level redundancy scenarios) to
	be able to indicate if a pseudowire is in a standby state, where it		be able to indicate if a pseudowire is in a standby state, where it
	is fully established by signaling and allows OAM, but is not		is fully established by signaling and allows OAM, but is not
	switching data. Again, such functionality is available for MPLS-		switching data. Again, such functionality is available for MPLS-
	based pseudowires using LDP, see [I-D.ietf-pwe3-redundancy-bit].		based pseudowires using LDP, see [I-D.ietf-pwe3-redundancy-bit].
	This document provides extended circuit status bit values for L2TPv3		This document provides extended circuit status bit values for L2TPv3
	and adds them in a manner such that it is backwards compatible with		and adds them in a manner such that it is backwards compatible with
	the current Circuit Status AVP. These new bits are applicable to all		the current Circuit Status AVP. These new bits are applicable to all
	skipping to change at page 4, line 18 ¶		skipping to change at page 4, line 18 ¶
	o The A (Active) bit indicates whether the circuit is up/active/		o The A (Active) bit indicates whether the circuit is up/active/
	ready (1) or down/inactive/not-ready (0).		ready (1) or down/inactive/not-ready (0).
	o The N (New) bit indicates whether the circuit status indication is		o The N (New) bit indicates whether the circuit status indication is
	for a new circuit (1) or an existing circuit (0).		for a new circuit (1) or an existing circuit (0).
	This document updates the semantics of the A and N bits as follows		This document updates the semantics of the A and N bits as follows
	(see also Section 4):		(see also Section 4):
	The A (Active) bit indicates whether the local pseudowire endpoint		The A (Active) bit indicates whether the local pseudowire endpoint
	(both local attachment circuit and local PSN-facing pseudowire) has		(both local Attachment Circuit (AC) and local Packet Switched Network
	no faults present and is up/active/ready (1) or has faults present		(PSN) facing pseudowire) has no faults present and is up/active/ready
	and is down/inactive/not-ready (0).		(1) or has faults present and is down/inactive/not-ready (0).
	The N (New) bit indicates if the notification is for a new circuit		The N (New) bit indicates if the notification is for a new circuit
	(1) or an existing circuit (0), and is provided to emulate (Frame		(1) or an existing circuit (0), and is provided to emulate (Frame
	Relay) NNI signaling between PEs. It MAY be used to convey that a		Relay) NNI signaling between Provider Edge (PE) routers. It MAY be
	circuit has been re-provisioned or newly provisioned at the PE, which		used to convey that a circuit has been re-provisioned or newly
	can already be inferred from the L2TP control message type. It is		provisioned at the PE, which can already be inferred from the L2TP
	therefore uncertain as to what use the receiving PE can make of this		control message type. It is therefore uncertain as to what use the
	bit, although it MAY include logging. This document deprecates this		receiving PE can make of this bit, although it MAY include logging.
	bit as it is of little or no use, hence this bit SHOULD be ignored on		This document deprecates this bit as it is of little or no use, hence
	receipt and is OPTIONAL to send. For reference, see Section 3.4 of		this bit SHOULD be ignored on receipt and is OPTIONAL to set on
	[RFC4591] which does not specify any additional usage beyond the		sending. For reference, see Section 3.4 of [RFC4591] which does not
	setting of in the ICRQ, ICRP (and OCRQ, OCRP) and clearing in all		specify any additional usage beyond the setting of the N bit in the
	other control messages.		ICRQ, ICRP (and OCRQ, OCRP) and clearing in all other control
			messages.
	This document also extends this bitmap of values to allow for finer		This document also extends this bitmap of values to allow for finer
	granularity of local pseudowire (i.e., access circuit or PSN-facing		granularity of local pseudowire (i.e., access circuit or PSN-facing
	endpoint) status reporting.		endpoint) status reporting.
	The Attribute Value field for the Circuit Status AVP including the		The Attribute Value field for the Circuit Status AVP including the
	new values has the following format:		new values has the following format:
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved |S|E|I|T|R|0|A|		| Reserved |S|E|I|T|R|N|A|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Bit Bit-Value Name		Bit Bit-Value Name
	-----------------------------------------------------------------		-----------------------------------------------------------------
	(A) 15 0x0001 Active: Pseudowire has no faults		(A) 15 0x0001 Active: Pseudowire has no faults
	(N) 14 0x0002 New [use deprecated]		(N) 14 0x0002 New [use deprecated]
	(R) 13 0x0004 Local Attachment Circuit (ingress) Receive Fault		(R) 13 0x0004 Local Attachment Circuit (ingress) Receive Fault
	(T) 12 0x0008 Local Attachment Circuit (egress) Transmit Fault		(T) 12 0x0008 Local Attachment Circuit (egress) Transmit Fault
	(I) 11 0x0010 Local PSN-facing PW (ingress) Receive Fault		(I) 11 0x0010 Local PSN-facing PW (ingress) Receive Fault
	(E) 10 0x0020 Local PSN-facing PW (egress) Transmit Fault		(E) 10 0x0020 Local PSN-facing PW (egress) Transmit Fault
	skipping to change at page 6, line 40 ¶		skipping to change at page 6, line 40 ¶
	|		|
	|		|
	Fault Here		Fault Here
	A fault has occurred in the receive direction between the local		A fault has occurred in the receive direction between the local
	endpoint and the remote L2TP endpoint.		endpoint and the remote L2TP endpoint.
	Note that a fault at the session level would not necessarily		Note that a fault at the session level would not necessarily
	trigger an L2TP control connection timeout. The means of		trigger an L2TP control connection timeout. The means of
	detecting this fault are outside the scope of this document; as an		detecting this fault are outside the scope of this document; as an
	example, detection may be via PW Type-specific means, BFD, or		example, detection may be via PW Type-specific means,
	other methods.		Bidirectional Forwarding Detection (BFD), or other methods.
	(E), Local PSN-facing PW (egress) Transmit Fault		(E), Local PSN-facing PW (egress) Transmit Fault
	Fault Here		Fault Here
	|		|
	|		|
	+----------------------+ | +----------------------+		+----------------------+ | +----------------------+
	Rx| LCCE |Egress| | Peer LCCE |		Rx| LCCE |Egress| | Peer LCCE |
	----->| |------X->| |		----->| |------X->| |
	| L2TPv3 | [PSN] | L2TPv3 |		| L2TPv3 | [PSN] | L2TPv3 |
	skipping to change at page 8, line 8 ¶		skipping to change at page 8, line 8 ¶
	A standby pseudowire also allows for means to check its data plane		A standby pseudowire also allows for means to check its data plane
	liveness, to ensure its ability to switch data packets end-to-end.		liveness, to ensure its ability to switch data packets end-to-end.
	This is achieved for example as detailed in [RFC5085] or		This is achieved for example as detailed in [RFC5085] or
	[I-D.ietf-pwe3-vccv-bfd]. However, data is not forwarded from an		[I-D.ietf-pwe3-vccv-bfd]. However, data is not forwarded from an
	Access Circuit (AC) into the L2TPv3 session, or from the L2TPv3		Access Circuit (AC) into the L2TPv3 session, or from the L2TPv3
	session out of the AC.		session out of the AC.
	3. Circuit Status Usage and Clarifications		3. Circuit Status Usage and Clarifications
			In implementations prior to this specification, bits 0-13 MUST be set
			to zero (see Section 5.4.5 of [RFC3931]). This allows for legacy
			implementations to interwork properly with new implementations.
	The following are clarifications regarding the usage of the Circuit		The following are clarifications regarding the usage of the Circuit
	Status AVP bits:		Status AVP bits as defined in this specification:
	o The (R), (T), (I) and (E) bits are collectively referred to as		o The (R), (T), (I) and (E) bits are collectively referred to as
	"fault status bits".		"fault status bits".
	o [RFC3931] defined the (A) bit as pertaining to local access		o [RFC3931] defined the (A) bit as pertaining to local access
	circuit state only. This draft redefines it as meaning that "no		circuit state only. This draft redefines it as meaning that "no
	faults are present on the local pseudowire endpoint."		faults are present on the local pseudowire endpoint."
	o If multiple faults occur, all the fault status bits corresponding		o If multiple faults occur, all the fault status bits corresponding
	to each fault MUST be set (i.e., they MUST be bitwise-OR-d		to each fault MUST be set (i.e., they MUST be bitwise-OR-d
	skipping to change at page 9, line 19 ¶		skipping to change at page 9, line 24 ¶
	(Frame Relay over L2TPv3), and Section 2.3.3 of [RFC4719] (Ethernet		(Frame Relay over L2TPv3), and Section 2.3.3 of [RFC4719] (Ethernet
	Frames over L2TPv3). This document updates the definitions in all		Frames over L2TPv3). This document updates the definitions in all
	these five references to say:		these five references to say:
	The A (Active) bit indicates whether the local pseudowire endpoint		The A (Active) bit indicates whether the local pseudowire endpoint
	(both local attachment circuit and local PSN-facing pseudowire)		(both local attachment circuit and local PSN-facing pseudowire)
	has no faults present and is up/active/ready (1) or has faults		has no faults present and is up/active/ready (1) or has faults
	present and is down/inactive/not-ready (0).		present and is down/inactive/not-ready (0).
	The N (New) bit usage is deprecated, it SHOULD be ignored on		The N (New) bit usage is deprecated, it SHOULD be ignored on
	receipt and is OPTIONAL to send.		receipt and is OPTIONAL to set on sending.
	This document also updates Section 2.2 (bullet c) of [RFC4719],		This document also updates Section 2.2 (bullet c) of [RFC4719],
	removing the following two sentences:		removing the following two sentences:
	For ICRQ and ICRP, the Circuit Status AVP MUST indicate that the		For ICRQ and ICRP, the Circuit Status AVP MUST indicate that the
	circuit status is for a new circuit (refer to N bit in Section		circuit status is for a new circuit (refer to N bit in Section
	2.3.3).		2.3.3).
	For ICCN and SLI (refer to Section 2.3.2), the Circuit Status AVP		For ICCN and SLI (refer to Section 2.3.2), the Circuit Status AVP
	MUST indicate that the circuit status is for an existing circuit		MUST indicate that the circuit status is for an existing circuit
	skipping to change at page 9, line 46 ¶		skipping to change at page 10, line 7 ¶
	The usage of the N bit in the Circuit Status AVP is deprecated.		The usage of the N bit in the Circuit Status AVP is deprecated.
	Therefore, for ICRQ and ICRP the Circuit Status AVP need not		Therefore, for ICRQ and ICRP the Circuit Status AVP need not
	indicate on sending (nor check on receipt) that the circuit status		indicate on sending (nor check on receipt) that the circuit status
	is for a new circuit, and for ICCN and SLI the Circuit Status AVP		is for a new circuit, and for ICCN and SLI the Circuit Status AVP
	need not indicate on sending (nor check on receipt) that the		need not indicate on sending (nor check on receipt) that the
	circuit status is for an existing circuit.		circuit status is for an existing circuit.
	5. Security Considerations		5. Security Considerations
	No additional security considerations exist with extending this		Security considerations for the Circuit Status AVP are covered in the
			base L2TPv3 specitication (see Section 8 of [RFC3931]). No
			additional security considerations exist with extending this
	attribute.		attribute.
	6. IANA Considerations		6. IANA Considerations
	The Circuit Status Bits number space reachable at		The Circuit Status Bits number space reachable at
	[IANA.l2tp-parameters] is managed by IANA as per Section 10.7 of		[IANA.l2tp-parameters] is managed by IANA as per Section 10.7 of
	[RFC3931]. Five new bits (bits 9 through 13) and one updated bit		[RFC3931]. Five new bits (bits 9 through 13) and one updated bit
	(bit 14) are requested to be assigned as follows:		(bit 14) are requested to be assigned as follows:
	Circuit Status Bits - per [RFC3931]		Circuit Status Bits - per [RFC3931]
	skipping to change at page 11, line 19 ¶		skipping to change at page 11, line 27 ¶
	[I-D.ietf-pwe3-redundancy-bit]		[I-D.ietf-pwe3-redundancy-bit]
	Muley, P., Bocci, M., and L. Martini, "Preferential		Muley, P., Bocci, M., and L. Martini, "Preferential
	Forwarding Status bit definition",		Forwarding Status bit definition",
	draft-ietf-pwe3-redundancy-bit-01 (work in progress),		draft-ietf-pwe3-redundancy-bit-01 (work in progress),
	September 2008.		September 2008.
	[I-D.ietf-pwe3-vccv-bfd]		[I-D.ietf-pwe3-vccv-bfd]
	Nadeau, T. and C. Pignataro, "Bidirectional Forwarding		Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
	Detection (BFD) for the Pseudowire Virtual Circuit		Detection (BFD) for the Pseudowire Virtual Circuit
	Connectivity Verification (VCCV)",		Connectivity Verification (VCCV)",
	draft-ietf-pwe3-vccv-bfd-03 (work in progress),		draft-ietf-pwe3-vccv-bfd-05 (work in progress), June 2009.
	February 2009.
	[IANA.l2tp-parameters]		[IANA.l2tp-parameters]
	Internet Assigned Numbers Authority, "Layer Two Tunneling		Internet Assigned Numbers Authority, "Layer Two Tunneling
	Protocol "L2TP"", March 2009,		Protocol "L2TP"", March 2009,
	<http://www.iana.org/assignments/l2tp-parameters>.		<http://www.iana.org/assignments/l2tp-parameters>.
	[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge		[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
	Emulation (PWE3)", BCP 116, RFC 4446, April 2006.		Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
	[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.		[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
End of changes. 16 change blocks.
	30 lines changed or deleted		36 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/