draft-ietf-mpls-ttl-00.txt		draft-ietf-mpls-ttl-01.txt
	Internet Draft Puneet Agarwal		Internet Draft Puneet Agarwal
	Pluris		Pluris
	Bora A. Akyol		Bora A. Akyol
	Document: draft-ietf-mpls-ttl-00.txt Cisco Systems		Document: draft-ietf-mpls-ttl-01.txt Cisco Systems
	Category: Informational		Category: Informational
	Expires: August 2002 February 2002		Expires: November 2002 May 2002
	TTL Processing in MPLS Networks		TTL Processing in MPLS Networks
	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 34		skipping to change at line 34
	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. TTL processing in both pipe and uniform model hierarchical
			tunnels are specified with examples for both "push" and "pop" cases.
			The document also complements [MPLS-DS] 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-01.txt 1
			TTL Processing in MPLS Networks May 2002
	1. Introduction and Motivation		1. Introduction and Motivation
	This document describes TTL processing in hierarchical MPLS		This document describes TTL processing in hierarchical MPLS
	networks. We believe that this document adds details that have not		networks. We believe that this document adds details that have not
	been addressed in [MPLS-ARCH, MPLS-ENCAPS], and that the methods		been addressed in [MPLS-ARCH, MPLS-ENCAPS], and that the methods
	presented in this document complement [MPLS-DS].		presented in this document complement [MPLS-DS].
	Agarwal & Akyol draft-ietf-mpls-ttl-00.txt 1
	TTL Processing in MPLS Networks January 2002
	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
	will address these 2 models and for completeness will also		will address 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
	will address this issue.		will address this issue.
	c) [MPLS-ENCAPS] does not define TTL processing in the presence		c) [MPLS-ENCAPS] does not define TTL processing in the presence
	of Penultimate Hop Popping (PHP). This draft will address		of Penultimate Hop Popping (PHP). This draft will address
	this issue.		this issue.
	skipping to change at line 80		skipping to change at line 86
	b. TTL (8 bits)		b. TTL (8 bits)
	c. Bottom of stack (1 bit)		c. Bottom of stack (1 bit)
	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
	conduit 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
	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
	Penultimate Hop Pop (PHP) is also described in this document. For a		Penultimate Hop Pop (PHP) is also described in this document. For a
	detailed description of Pipe and Uniform models, please see [MPLS-		detailed description of Pipe and Uniform models, please see [MPLS-
	DS].		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-01.txt 2
			TTL Processing in MPLS Networks May 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 treatment for TTL behavior using		We also note here that signaling treatment for TTL behavior using
	either RSVP-TE or LDP is out of the scope of this document.		either RSVP-TE or LDP is out of the scope of this document.
	Agarwal & Akyol draft-ietf-mpls-ttl-00.txt 2
	TTL Processing in MPLS Networks January 2002
	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.
	oTTL Check: Check if oTTL is greater than 0. If the oTTL Check is		oTTL Check: Check if oTTL is greater than 0. If the oTTL Check is
	skipping to change at line 146		skipping to change at line 153
	(n) represents the TTL value in the corresponding header		(n) represents the TTL value in the corresponding header
	(x) represents non-meaningful TLL information		(x) represents non-meaningful TLL 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-00.txt 3		Agarwal & Akyol draft-ietf-mpls-ttl-01.txt 3
	TTL Processing in MPLS Networks January 2002		TTL Processing in MPLS Networks May 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 172		skipping to change at line 179
	(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.
	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)-(E)-(n-2)->		>--(n)--Push.............(n-1)............Pop-(n-1)-Decr.-(n-2)->
	(I) (inner header) (P)
			(I) (inner header) (P) (E)
	(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
	(P) represents the LSP penultimate node		(P) represents the LSP penultimate node
	(E) represents the LSP Egress node		(E) represents the LSP egress node.
	Note that at the end of short pipe model LSP the TTL of the tunneled		Since the label has already the popped by the LSP penultimate node,
	packet has been decremented by two either with or without PHP.		the LSP egress node just decrements the header TTL.
	Agarwal & Akyol draft-ietf-mpls-ttl-00.txt 4		Also note that at the end of short pipe model LSP, the TTL of the
	TTL Processing in MPLS Networks January 2002		tunneled packet has been decremented by two either with or without
			PHP.
			Agarwal & Akyol draft-ietf-mpls-ttl-01.txt 4
			TTL Processing in MPLS Networks May 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)->
	skipping to change at line 241		skipping to change at line 254
	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-00.txt 5		Agarwal & Akyol draft-ietf-mpls-ttl-01.txt 5
	TTL Processing in MPLS Networks January 2002		TTL Processing in MPLS Networks May 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
	as described in (1). The TTL value(s) of any pushed label(s)		as described in (1). The TTL value(s) of any pushed label(s)
	are determined as described in section 3.6.		are determined as described in section 3.6.
	3) Penultimate Hop Pop (PHP): The routed label is popped. The		3) Penultimate Hop Pop (PHP): The routed label is popped. The
	oTTL check should be performed irrespective of whether the oTTL		oTTL check should be performed irrespective of whether the
	is used to update the TTL field of the outgoing header. If the		oTTL is used to update the TTL field of the outgoing header.
	PHPed label belonged to a short Pipe model LSP, then the TTL		If the PHPed label belonged to a short Pipe model LSP, then
	field of the PHP exposed header is neither checked nor		the TTL field of the PHP exposed header is neither checked
	updated. If the PHPed label was a Uniform model LSP, then the		nor updated. If the PHPed label was a Uniform model LSP,
	TTL field of the PHP exposed header is set to the oTTL. The TTL		then the TTL field of the PHP exposed header is set to the
	value(s) of additional labels are determined as described in		oTTL. The TTL value(s) of additional labels are determined
	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.
	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		1) Although iTTL can be decremented by a value larger than 1
	than 1 while it is being updated or oTTL is being		while it is being updated or oTTL is being determined, this
	determined, this feature should be only used for		feature should be only used for compensating for network
	compensating for network nodes that are not capable of		nodes that are not capable of decrementing TTL values.
	decrementing TTL values.
	2) Whenever iTTL is decremented, the implementor must		2) Whenever iTTL is decremented, the implementor must make sure
	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 tunneled packet is unchanged after the PHP		3) In the short pipe model with PHP enabled, the TTL of the
	operation.		tunneled packet is unchanged after the PHP operation.
			Agarwal & Akyol draft-ietf-mpls-ttl-01.txt 6
			TTL Processing in MPLS Networks May 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.
	Agarwal & Akyol draft-ietf-mpls-ttl-00.txt 6
	TTL Processing in MPLS Networks January 2002
	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].		ones defined in [MPLS-ENCAPS, MPLS-DS]. In particular, the document
			does not define a new protocol or expand an existing one and does
			not introduce security problems into the existing protocols. The
			authors believe that clarification of TTL handling in MPLS networks
			benefits service providers and their customers since troubleshooting
			is simplified.
	6. References		6. 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.
	[MPLS-DS] F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen,		[MPLS-DS] F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen,
	skipping to change at line 332		skipping to change at line 351
	10455 Bandley Drive		10455 Bandley Drive
	Cupertino, CA 95014		Cupertino, CA 95014
	Email: puneet@pluris.com		Email: puneet@pluris.com
	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-00.txt 7		Agarwal & Akyol draft-ietf-mpls-ttl-01.txt 7
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/