draft-ietf-mpls-ttl-03.txt		draft-ietf-mpls-ttl-04.txt
	Internet Draft Puneet Agarwal		Internet Draft Puneet Agarwal
	Pluris		Brocade
	Bora A. Akyol		Bora A. Akyol
	Document: draft-ietf-mpls-ttl-03.txt Cisco Systems		Document: draft-ietf-mpls-ttl-04.txt Cisco Systems
	Category: Standards Track		Category: Standards Track
	Expires: December 2002 June 2002		Expires: May 2003 November 2002
	Time to Live (TTL) Processing in MPLS Networks (Updates RFC 3032)		Time to Live (TTL) Processing in MPLS Networks (Updates RFC 3032)
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance		This document is an Internet-Draft and is in full conformance
	with all provisions of Section 10 of RFC2026.		with all provisions of Section 10 of RFC2026.
	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 line 33		skipping to change at line 33
	at any time. It is inappropriate to use Internet-Drafts as		at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."		reference 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.
	Abstract		Abstract
	This document describes TTL processing in hierarchical MPLS		This document describes TTL processing in hierarchical MPLS networks
	networks. It updates rfc-3032 "MPLS Label Stack Encoding". TTL		and is motivated by the need to formalize a TTL-transparent mode of
	processing in both pipe and uniform model hierarchical tunnels are		operation for an MPLS label-switched path. It updates RFC-3032 "MPLS
	specified with examples for both "push" and "pop" cases. The		Label Stack Encoding". TTL processing in both pipe and uniform model
	document also complements rfc-3270 "MPLS Support of Differentiated		hierarchical tunnels are specified with examples for both "push" and
	Services" and ties together the terminology introduced in that		"pop" cases. The document also complements RFC-3270 "MPLS Support of
	document with TTL processing in hierarchical MPLS networks.		Differentiated Services" and ties together the terminology
			introduced in that document with TTL processing in hierarchical MPLS
			networks.
	Conventions used in this document		Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	this document are to be interpreted as described in [RFC-2119].		this document are to be interpreted as described in [RFC-2119].
	Agarwal & Akyol draft-ietf-mpls-ttl-03.txt 1		Agarwal & Akyol draft-ietf-mpls-ttl-04.txt 1
	Time to Live (TTL) Processing in MPLS Networks June 2002		Time to Live (TTL) Processing in MPLS Networks November 2002
	1. Introduction and Motivation		1. Introduction and Motivation
	This document describes Time to Live (TTL) processing in		This document describes Time to Live (TTL) processing in
	hierarchical MPLS networks. We believe that this document adds		hierarchical MPLS networks. We believe that this document adds
	details that have not been addressed in [MPLS-ARCH, MPLS-ENCAPS],		details that have not been addressed in [MPLS-ARCH, MPLS-ENCAPS],
	and that the methods presented in this document complement [MPLS-		and that the methods presented in this document complement [MPLS-
	DS].		DS].
			In particular, a new mode of operation (referred to as the pipe
			model) is introduced to support the practice of configuring MPLS
			LSPs such that packets transiting that LSP see the tunnel as a
			single hop regardless of the number of intermediary label switch
			routers (LSR). The pipe model for TTL is currently being used in
			multiple networks and is provided as an option configurable by the
			network operator by several vendors.
			This document formalizes the TTL processing in MPLS networks and
			ties it with the terminology introduced in [MPLS-DS].
	2. TTL Processing in MPLS Networks		2. TTL Processing in MPLS Networks
	2.1. Changes to RFC 3032 [MPLS-ENCAPS]		2.1. Changes to RFC 3032 [MPLS-ENCAPS]
	a) [MPLS-ENCAPS] only covers the Uniform Model and does NOT		a) [MPLS-ENCAPS] only covers the Uniform Model and does NOT
	address the Pipe Model or the Short Pipe Model. This draft		address the Pipe Model or the Short Pipe Model. This draft
	addresses these 2 models and for completeness will also		addresses these 2 models and for completeness will also
	address the Uniform Model.		address the Uniform Model.
	b) [MPLS-ENCAPS] does not cover hierarchical LSPs. This draft		b) [MPLS-ENCAPS] does not cover hierarchical LSPs. This draft
	addresses this issue.		addresses this issue.
	skipping to change at line 90		skipping to change at line 103
	d. Experimental bits (3 bits)		d. Experimental bits (3 bits)
	The experimental bits were later redefined in [MPLS-DS] to indicate		The experimental bits were later redefined in [MPLS-DS] to indicate
	the scheduling and shaping behavior that could be associated with a		the scheduling and shaping behavior that could be associated with a
	MPLS packet.		MPLS packet.
	[MPLS-DS] also defined two models for MPLS tunnel operation: Pipe		[MPLS-DS] also defined two models for MPLS tunnel operation: Pipe
	and Uniform models. In the Pipe model, a MPLS network acts like a		and Uniform models. In the Pipe model, a MPLS network acts like a
	circuit when MPLS packets traverse the network such that only the		circuit when MPLS packets traverse the network such that only the
	LSP ingress and egress points are visible to nodes that are outside		LSP ingress and egress points are visible to nodes that are outside
			Agarwal & Akyol draft-ietf-mpls-ttl-04.txt 2
			Time to Live (TTL) Processing in MPLS Networks November 2002
	the tunnel. A Short variation of the Pipe Model is also defined in		the tunnel. A Short variation of the Pipe Model is also defined in
	[MPLS-DS] to differentiate between different egress forwarding and		[MPLS-DS] to differentiate between different egress forwarding and
	QoS treatments. On the other hand, the Uniform model makes all the		QoS treatments. On the other hand, the Uniform model makes all the
	nodes that a LSP traverses visible to nodes outside the tunnel. We		nodes that a LSP traverses visible to nodes outside the tunnel. We
	will extend the Pipe and Uniform models to include TTL processing in		will extend the Pipe and Uniform models to include TTL processing in
	the following sections. Furthermore, TTL processing when performing		the following sections. Furthermore, TTL processing when performing
	PHP is also described in this document. For a detailed description		PHP is also described in this document. For a detailed description
	of Pipe and Uniform models, please see [MPLS-DS].		of Pipe and Uniform models, please see [MPLS-DS].
	TTL processing in MPLS networks can be broken down into two logical		TTL processing in MPLS networks can be broken down into two logical
	blocks: (i) the incoming TTL determination to take into account any		blocks: (i) the incoming TTL determination to take into account any
	Agarwal & Akyol draft-ietf-mpls-ttl-03.txt 2
	Time to Live (TTL) Processing in MPLS Networks June 2002
	tunnel egress due to MPLS Pop operations; (ii) packet processing of		tunnel egress due to MPLS Pop operations; (ii) packet processing of
	(possibly) exposed packet & outgoing TTL.		(possibly) exposed packet & outgoing TTL.
	We also note here that signaling the LSP type (pipe, short pipe or		We also note here that signaling the LSP type (pipe, short pipe or
	uniform model) is out of the scope of this document, and that is		uniform model) is out of the scope of this document, and that is
	also not addressed in the current versions of the label distribution		also not addressed in the current versions of the label distribution
	protocols, e.g. LDP [MPLS-LDP] and RSVP-TE [MPLS-RSVP].		protocols, e.g. LDP [MPLS-LDP] and RSVP-TE [MPLS-RSVP]. Currently,
			the LSP type is configured by the network operator manually by means
			of either a command line or network management interface.
	2.3. New Terminology		2.3. New Terminology
	iTTL: The TTL value to use as the incoming TTL. No checks are		iTTL: The TTL value to use as the incoming TTL. No checks are
	performed on the iTTL.		performed on the iTTL.
	oTTL: This is the TTL value used as the outgoing TTL value (see		oTTL: This is the TTL value used as the outgoing TTL value (see
	section 3.5 for exception). It is always (iTTL - 1) unless otherwise		section 3.5 for exception). It is always (iTTL - 1) unless otherwise
	stated.		stated.
	skipping to change at line 133		skipping to change at line 148
	false, then the packet is not forwarded. Note that the oTTL check is		false, then the packet is not forwarded. Note that the oTTL check is
	performed only if any outgoing TTL (either IP or MPLS) is set to		performed only if any outgoing TTL (either IP or MPLS) is set to
	oTTL (see section 3.5 for exception).		oTTL (see section 3.5 for exception).
	3. TTL Processing in different Models		3. TTL Processing in different Models
	This section describes the TTL processing for LSPs conforming to		This section describes the TTL processing for LSPs conforming to
	each of the 3 models (Uniform, Short Pipe and Pipe) in the		each of the 3 models (Uniform, Short Pipe and Pipe) in the
	presence/absence of PHP (where applicable).		presence/absence of PHP (where applicable).
			Agarwal & Akyol draft-ietf-mpls-ttl-04.txt 3
			Time to Live (TTL) Processing in MPLS Networks November 2002
	3.1. TTL Processing for Uniform Model LSPs (with or without PHP)		3.1. TTL Processing for Uniform Model LSPs (with or without PHP)
	(consistent with [MPLS-ENCAPS]):		(consistent with [MPLS-ENCAPS]):
	========== LSP =============================>		========== LSP =============================>
	+--Swap--(n-2)-...-swap--(n-i)---+		+--Swap--(n-2)-...-swap--(n-i)---+
	/ (outer header) \		/ (outer header) \
	(n-1) (n-i)		(n-1) (n-i)
	/ \		/ \
	skipping to change at line 156		skipping to change at line 174
	(n) represents the TTL value in the corresponding header		(n) represents the TTL value in the corresponding header
	(x) represents non-meaningful TTL information		(x) represents non-meaningful TTL information
	(I) represents the LSP ingress node		(I) represents the LSP ingress node
	(P) represents the LSP penultimate node		(P) represents the LSP penultimate node
	(E) represents the LSP Egress node		(E) represents the LSP Egress node
	This picture shows TTL processing for a uniform model MPLS LSP. Note		This picture shows TTL processing for a uniform model MPLS LSP. Note
	that the inner and outer TTLs of the packets are synchronized at		that the inner and outer TTLs of the packets are synchronized at
	tunnel ingress and egress.		tunnel ingress and egress.
	Agarwal & Akyol draft-ietf-mpls-ttl-03.txt 3
	Time to Live (TTL) Processing in MPLS Networks June 2002
	3.2. TTL Processing for Short Pipe Model LSPs		3.2. TTL Processing for Short Pipe Model LSPs
	3.2.1. TTL Processing for Short Pipe Model LSPs without PHP		3.2.1. TTL Processing for Short Pipe Model LSPs without PHP
	========== LSP =============================>		========== LSP =============================>
	+--Swap--(N-1)-...-swap--(N-i)-----+		+--Swap--(N-1)-...-swap--(N-i)-----+
	/ (outer header) \		/ (outer header) \
	(N) (N-i)		(N) (N-i)
	/ \		/ \
	skipping to change at line 181		skipping to change at line 196
	(N) represents the TTL value (may have no relationship to n)		(N) represents the TTL value (may have no relationship to n)
	(n) represents the tunneled TTL value in the encapsulated header		(n) represents the tunneled TTL value in the encapsulated header
	(I) represents the LSP ingress node		(I) represents the LSP ingress node
	(E) represents the LSP Egress node		(E) represents the LSP Egress node
	Short Pipe Model was introduced in [MPLS-DS]. In the short pipe		Short Pipe Model was introduced in [MPLS-DS]. In the short pipe
	model, the forwarding treatment at the egress LSR is based on the		model, the forwarding treatment at the egress LSR is based on the
	tunneled packet as opposed to the encapsulating packet.		tunneled packet as opposed to the encapsulating packet.
			Agarwal & Akyol draft-ietf-mpls-ttl-04.txt 4
			Time to Live (TTL) Processing in MPLS Networks November 2002
	3.2.2. TTL Processing for Short Pipe Model with PHP:		3.2.2. TTL Processing for Short Pipe Model with PHP:
	========== LSP =====================================>		========== LSP =====================================>
	+-Swap-(N-1)-...-swap-(N-i)-+		+-Swap-(N-1)-...-swap-(N-i)-+
	/ (outer header) \		/ (outer header) \
	(N) (N-i)		(N) (N-i)
	/ \		/ \
	>--(n)--Push.............(n-1)............Pop-(n-1)-Decr.-(n-2)->		>--(n)--Push.............(n-1)............Pop-(n-1)-Decr.-(n-2)->
	(I) (inner header) (P) (E)		(I) (inner header) (P) (E)
	skipping to change at line 204		skipping to change at line 222
	(P) represents the LSP penultimate node		(P) represents the LSP penultimate node
	(E) represents the LSP egress node.		(E) represents the LSP egress node.
	Since the label has already been popped by the LSP's penultimate		Since the label has already been popped by the LSP's penultimate
	node, the LSP egress node just decrements the header TTL.		node, the LSP egress node just decrements the header TTL.
	Also note that at the end of short pipe model LSP, the TTL of the		Also note that at the end of short pipe model LSP, the TTL of the
	tunneled packet has been decremented by two either with or without		tunneled packet has been decremented by two either with or without
	PHP.		PHP.
	Agarwal & Akyol draft-ietf-mpls-ttl-03.txt 4
	Time to Live (TTL) Processing in MPLS Networks June 2002
	3.3. TTL Processing for Pipe Model LSPs (without PHP only):		3.3. TTL Processing for Pipe Model LSPs (without PHP only):
	========== LSP =============================>		========== LSP =============================>
	+--Swap--(N-1)-...-swap--(N-i)-----+		+--Swap--(N-1)-...-swap--(N-i)-----+
	/ (outer header) \		/ (outer header) \
	(N) (N-i)		(N) (N-i)
	/ \		/ \
	>--(n)--Push...............(n-1)....................Pop--(n-2)->		>--(n)--Push...............(n-1)....................Pop--(n-2)->
	(I) (inner header) (E)		(I) (inner header) (E)
	skipping to change at line 235		skipping to change at line 250
	3.4. Incoming TTL (iTTL) determination		3.4. Incoming TTL (iTTL) determination
	If the incoming packet is an IP packet, then the iTTL is the TTL		If the incoming packet is an IP packet, then the iTTL is the TTL
	value of the incoming IP packet.		value of the incoming IP packet.
	If the incoming packet is a MPLS packet and we are performing a		If the incoming packet is a MPLS packet and we are performing a
	Push/Swap/PHP, then the iTTL is the TTL of the topmost incoming		Push/Swap/PHP, then the iTTL is the TTL of the topmost incoming
	label.		label.
			Agarwal & Akyol draft-ietf-mpls-ttl-04.txt 5
			Time to Live (TTL) Processing in MPLS Networks November 2002
	If the incoming packet is a MPLS packet and we are performing a Pop		If the incoming packet is a MPLS packet and we are performing a Pop
	(tunnel termination), the iTTL is based on the tunnel type (Pipe or		(tunnel termination), the iTTL is based on the tunnel type (Pipe or
	Uniform) of the LSP that was popped. If the popped label belonged to		Uniform) of the LSP that was popped. If the popped label belonged to
	a Pipe model LSP, then the iTTL is the value of the TTL field of the		a Pipe model LSP, then the iTTL is the value of the TTL field of the
	header exposed after the label was popped (note that for the purpose		header exposed after the label was popped (note that for the purpose
	of this draft, the exposed header may be either an IP header or an		of this draft, the exposed header may be either an IP header or an
	MPLS label). If the popped label belonged to a Uniform model LSP,		MPLS label). If the popped label belonged to a Uniform model LSP,
	then the iTTL is equal to the TTL of the popped label. If multiple		then the iTTL is equal to the TTL of the popped label. If multiple
	Pop operations are performed sequentially, then the procedure given		Pop operations are performed sequentially, then the procedure given
	above is repeated with one exception: the iTTL computed during the		above is repeated with one exception: the iTTL computed during the
	skipping to change at line 256		skipping to change at line 274
	i.e. the TTL contained in the subsequent label is essentially		i.e. the TTL contained in the subsequent label is essentially
	ignored and replaced with the iTTL computed during the previous pop.		ignored and replaced with the iTTL computed during the previous pop.
	3.5. Outgoing TTL Determination and Packet Processing		3.5. Outgoing TTL Determination and Packet Processing
	After the iTTL computation is performed, the oTTL check is performed.		After the iTTL computation is performed, the oTTL check is performed.
	If the oTTL check succeeds, then the outgoing TTL of the		If the oTTL check succeeds, then the outgoing TTL of the
	(labeled/unlabeled) packet is calculated and packet headers are		(labeled/unlabeled) packet is calculated and packet headers are
	updated as defined below.		updated as defined below.
	Agarwal & Akyol draft-ietf-mpls-ttl-03.txt 5
	Time to Live (TTL) Processing in MPLS Networks June 2002
	If the packet was routed as an IP packet, the TTL value of the IP		If the packet was routed as an IP packet, the TTL value of the IP
	packet is set to oTTL (iTTL - 1). The TTL value(s) for any pushed		packet is set to oTTL (iTTL - 1). The TTL value(s) for any pushed
	label(s) are determined as described in section 3.6.		label(s) are determined as described in section 3.6.
	For packets that are routed as MPLS, we have four cases:		For packets that are routed as MPLS, we have four cases:
	1) Swap-only: The routed label is swapped with another label		1) Swap-only: The routed label is swapped with another label
	and the TTL field of the outgoing label is set to oTTL.		and the TTL field of the outgoing label is set to oTTL.
	2) Swap followed by a Push: The swapped operation is performed		2) Swap followed by a Push: The swapped operation is performed
	skipping to change at line 290		skipping to change at line 305
	as described in section 3.6		as described in section 3.6
	4) Pop: The pop operation happens before routing and hence it		4) Pop: The pop operation happens before routing and hence it
	is not considered here.		is not considered here.
	3.6. Tunnel Ingress Processing (Push)		3.6. Tunnel Ingress Processing (Push)
	For each pushed Uniform model label, the TTL is copied from the		For each pushed Uniform model label, the TTL is copied from the
	label/IP-packet immediately underneath it.		label/IP-packet immediately underneath it.
			Agarwal & Akyol draft-ietf-mpls-ttl-04.txt 6
			Time to Live (TTL) Processing in MPLS Networks November 2002
	For each pushed Pipe model or Short Pipe model label, the TTL field		For each pushed Pipe model or Short Pipe model label, the TTL field
	is set to a value configured by the network operator. In most		is set to a value configured by the network operator. In most
	implementations, this value is set to 255 by default.		implementations, this value is set to 255 by default.
	3.7. Implementation Remarks		3.7. Implementation Remarks
	1) Although iTTL can be decremented by a value larger than 1		1) Although iTTL can be decremented by a value larger than 1
	while it is being updated or oTTL is being determined, this		while it is being updated or oTTL is being determined, this
	feature should be only used for compensating for network		feature should be only used for compensating for network
	nodes that are not capable of decrementing TTL values.		nodes that are not capable of decrementing TTL values.
	2) Whenever iTTL is decremented, the implementer must make sure		2) Whenever iTTL is decremented, the implementer must make sure
	that the value does not go negative.		that the value does not go negative.
	3) In the short pipe model with PHP enabled, the TTL of the		3) In the short pipe model with PHP enabled, the TTL of the
	tunneled packet is unchanged after the PHP operation.		tunneled packet is unchanged after the PHP operation.
	Agarwal & Akyol draft-ietf-mpls-ttl-03.txt 6
	Time to Live (TTL) Processing in MPLS Networks June 2002
	4. Conclusion		4. Conclusion
	This Internet Draft describes how TTL field can be processed in a		This Internet Draft describes how TTL field can be processed in a
	MPLS network. We clarified the various methods that are applied in		MPLS network. We clarified the various methods that are applied in
	the presence of hierarchical tunnels and completed the integration		the presence of hierarchical tunnels and completed the integration
	of Pipe and Uniform models with TTL processing.		of Pipe and Uniform models with TTL processing.
	5. Security Considerations		5. Security Considerations
	This document does not add any new security issues other than the		This document does not add any new security issues other than the
	ones defined in [MPLS-ENCAPS, MPLS-DS]. In particular, the document		ones defined in [MPLS-ENCAPS, MPLS-DS]. In particular, the document
	does not define a new protocol or expand an existing one and does		does not define a new protocol or expand an existing one and does
	not introduce security problems into the existing protocols. The		not introduce security problems into the existing protocols. The
	authors believe that clarification of TTL handling in MPLS networks		authors believe that clarification of TTL handling in MPLS networks
	benefits service providers and their customers since troubleshooting		benefits service providers and their customers since troubleshooting
	is simplified.		is simplified.
			Agarwal & Akyol draft-ietf-mpls-ttl-04.txt 7
			Time to Live (TTL) Processing in MPLS Networks November 2002
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[MPLS-ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol		[MPLS-ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol
	Label Switching Architecture", RFC 3031.		Label Switching Architecture", RFC 3031.
	[MPLS-ENCAPS] E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D.		[MPLS-ENCAPS] E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D.
	Farinacci, T. Li, A. Conta, "MPLS Label Stack Encoding", RFC3032.		Farinacci, T. Li, A. Conta, "MPLS Label Stack Encoding", RFC3032.
	skipping to change at line 356		skipping to change at line 374
	[MPLS-RSVP] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G.		[MPLS-RSVP] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G.
	Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209.		Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209.
	7. Acknowledgements		7. Acknowledgements
	The authors would like to thank the members of the MPLS working		The authors would like to thank the members of the MPLS working
	group for their feedback. We would especially like to thank Shahram		group for their feedback. We would especially like to thank Shahram
	Davari and Loa Andersson for their careful review of the document		Davari and Loa Andersson for their careful review of the document
	and their comments.		and their comments.
	Agarwal & Akyol draft-ietf-mpls-ttl-03.txt 7
	Time to Live (TTL) Processing in MPLS Networks June 2002
	8. Author's Addresses		8. Author's Addresses
	Puneet Agarwal		Puneet Agarwal
	Pluris		Brocade Communications Systems, Inc.
	10455 Bandley Drive		1745 Technology Drive
	Cupertino, CA 95014		San Jose, CA 95110
	Email: puneet@pluris.com		Email: puneet@acm.org
	Bora Akyol		Bora Akyol
	Cisco Systems		Cisco Systems
	170 W. Tasman Drive		170 W. Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	Email: bora@cisco.com		Email: bora@cisco.com
	Agarwal & Akyol draft-ietf-mpls-ttl-03.txt 8		Agarwal & Akyol draft-ietf-mpls-ttl-04.txt 8
End of changes.
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/