draft-ietf-mpls-ttl-01.txt   draft-ietf-mpls-ttl-02.txt 
Internet Draft Puneet Agarwal Internet Draft Puneet Agarwal
Pluris Pluris
Bora A. Akyol Bora A. Akyol
Document: draft-ietf-mpls-ttl-01.txt Cisco Systems Document: draft-ietf-mpls-ttl-02.txt Cisco Systems
Category: Informational Category: Informational
Expires: November 2002 May 2002 Expires: November 2002 May 2002
TTL Processing in MPLS Networks Time to Live (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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at line 36 skipping to change at line 36
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. TTL processing in both pipe and uniform model hierarchical networks. TTL processing in both pipe and uniform model hierarchical
tunnels are specified with examples for both "push" and "pop" cases. tunnels are specified with examples for both "push" and "pop" cases.
The document also complements [MPLS-DS] and ties together the The document also complements rfc-3270 "MPLS Support of
terminology introduced in that document with TTL processing in Differentiated Services" and ties together the terminology
hierarchical MPLS networks. 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 Agarwal & Akyol draft-ietf-mpls-ttl-02.txt 1
TTL Processing in MPLS Networks May 2002 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 Time to Live (TTL) processing in
networks. We believe that this document adds details that have not hierarchical MPLS networks. We believe that this document adds
been addressed in [MPLS-ARCH, MPLS-ENCAPS], and that the methods details that have not been addressed in [MPLS-ARCH, MPLS-ENCAPS],
presented in this document complement [MPLS-DS]. and that the methods presented in this document complement [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
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
skipping to change at line 94 skipping to change at line 96
[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
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 PHP is also described in this document. For a detailed description
detailed description of Pipe and Uniform models, please see [MPLS- 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 Agarwal & Akyol draft-ietf-mpls-ttl-02.txt 2
TTL Processing in MPLS Networks May 2002 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 the LSP type (pipe, short pipe or
either RSVP-TE or LDP is out of the scope of this document. uniform model) is out of the scope of this document, and that is
also not addressed in the current versions of the label distribution
protocols, e.g. LDP [MPLS-LDP] and RSVP-TE [MPLS-RSVP].
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
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 sections 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).
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)
/ \ / \
>--(n)--Push...............(x).....................Pop--(n-i-1)-> >--(n)--Push...............(x).....................Pop--(n-i-1)->
(I) (inner header) (E or P) (I) (inner header) (E or P)
(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 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-01.txt 3 Agarwal & Akyol draft-ietf-mpls-ttl-02.txt 3
TTL Processing in MPLS Networks May 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) \
skipping to change at line 186 skipping to change at line 189
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)-Decr.-(n-2)-> >--(n)--Push.............(n-1)............Pop-(n-1)-Decr.-(n-2)->
(I) (inner header) (P) (E) (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.
Since the label has already the popped by the LSP penultimate node, Since the label has already been popped by the LSPÆs penultimate
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-01.txt 4 Agarwal & Akyol draft-ietf-mpls-ttl-02.txt 4
TTL Processing in MPLS Networks May 2002 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)
/ \ / \
skipping to change at line 254 skipping to change at line 256
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-01.txt 5 Agarwal & Akyol draft-ietf-mpls-ttl-02.txt 5
TTL Processing in MPLS Networks May 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.
skipping to change at line 299 skipping to change at line 301
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 implementor 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-01.txt 6 Agarwal & Akyol draft-ietf-mpls-ttl-02.txt 6
TTL Processing in MPLS Networks May 2002 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.
5. Security Considerations 5. Security Considerations
skipping to change at line 328 skipping to change at line 330
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.
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,
R. Krishnan, P. Cheval, J. Heinanen, "MPLS Support of Differentiated R. Krishnan, P. Cheval, J. Heinanen, "MPLS Support of Differentiated
Services," draft-ietf-mpls-diff-ext-09.txt. (Work in progress) Services", RFC3270.
7. Author's Addresses [MPLS-LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B.
Thomas, "LDP Specification", RFC 3036.
[MPLS-RSVP] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G.
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209.
7. Acknowledgements
The authors would like to thank the members of the MPLS working
group for their feedback. We would especially like to thank Shahram
Davari and Loa Andersson for their careful review of the document
and their comments.
Agarwal & Akyol draft-ietf-mpls-ttl-02.txt 7
TTL Processing in MPLS Networks May 2002
8. Author's Addresses
Puneet Agarwal Puneet Agarwal
Pluris Pluris
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-01.txt 7 Agarwal & Akyol draft-ietf-mpls-ttl-02.txt 8
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/