idnits 2.17.1 draft-ietf-mpls-ttl-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 261 has weird spacing: '... nor updat...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7979 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-2119' is mentioned on line 46, but not defined -- Obsolete informational reference (is this intentional?): RFC 3036 (ref. 'MPLS-LDP') (Obsoleted by RFC 5036) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Puneet Agarwal 3 Pluris 4 Bora A. Akyol 5 Document: draft-ietf-mpls-ttl-03.txt Cisco Systems 6 Category: Standards Track 7 Expires: December 2002 June 2002 9 Time to Live (TTL) Processing in MPLS Networks (Updates RFC 3032) 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document describes TTL processing in hierarchical MPLS 34 networks. It updates rfc-3032 "MPLS Label Stack Encoding". TTL 35 processing in both pipe and uniform model hierarchical tunnels are 36 specified with examples for both "push" and "pop" cases. The 37 document also complements rfc-3270 "MPLS Support of Differentiated 38 Services" and ties together the terminology introduced in that 39 document with TTL processing in hierarchical MPLS networks. 41 Conventions used in this document 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 45 this document are to be interpreted as described in [RFC-2119]. 47 1. Introduction and Motivation 49 This document describes Time to Live (TTL) processing in 50 hierarchical MPLS networks. We believe that this document adds 51 details that have not been addressed in [MPLS-ARCH, MPLS-ENCAPS], 52 and that the methods presented in this document complement [MPLS- 53 DS]. 55 2. TTL Processing in MPLS Networks 57 2.1. Changes to RFC 3032 [MPLS-ENCAPS] 59 a) [MPLS-ENCAPS] only covers the Uniform Model and does NOT 60 address the Pipe Model or the Short Pipe Model. This draft 61 addresses these 2 models and for completeness will also 62 address the Uniform Model. 63 b) [MPLS-ENCAPS] does not cover hierarchical LSPs. This draft 64 addresses this issue. 65 c) [MPLS-ENCAPS] does not define TTL processing in the presence 66 of Penultimate Hop Popping (PHP). This draft addresses this 67 issue. 69 2.2. Terminology and Background 71 As defined in [MPLS-ENCAPS], MPLS packets use a MPLS shim header 72 that indicates the following information about a packet: 74 a. MPLS Label (20 bits) 75 b. TTL (8 bits) 76 c. Bottom of stack (1 bit) 77 d. Experimental bits (3 bits) 79 The experimental bits were later redefined in [MPLS-DS] to indicate 80 the scheduling and shaping behavior that could be associated with a 81 MPLS packet. 83 [MPLS-DS] also defined two models for MPLS tunnel operation: Pipe 84 and Uniform models. In the Pipe model, a MPLS network acts like a 85 circuit when MPLS packets traverse the network such that only the 86 LSP ingress and egress points are visible to nodes that are outside 87 the tunnel. A Short variation of the Pipe Model is also defined in 88 [MPLS-DS] to differentiate between different egress forwarding and 89 QoS treatments. On the other hand, the Uniform model makes all the 90 nodes that a LSP traverses visible to nodes outside the tunnel. We 91 will extend the Pipe and Uniform models to include TTL processing in 92 the following sections. Furthermore, TTL processing when performing 93 PHP is also described in this document. For a detailed description 94 of Pipe and Uniform models, please see [MPLS-DS]. 96 TTL processing in MPLS networks can be broken down into two logical 97 blocks: (i) the incoming TTL determination to take into account any 98 tunnel egress due to MPLS Pop operations; (ii) packet processing of 99 (possibly) exposed packet & outgoing TTL. 101 We also note here that signaling the LSP type (pipe, short pipe or 102 uniform model) is out of the scope of this document, and that is 103 also not addressed in the current versions of the label distribution 104 protocols, e.g. LDP [MPLS-LDP] and RSVP-TE [MPLS-RSVP]. 106 2.3. New Terminology 108 iTTL: The TTL value to use as the incoming TTL. No checks are 109 performed on the iTTL. 111 oTTL: This is the TTL value used as the outgoing TTL value (see 112 section 3.5 for exception). It is always (iTTL - 1) unless otherwise 113 stated. 115 oTTL Check: Check if oTTL is greater than 0. If the oTTL Check is 116 false, then the packet is not forwarded. Note that the oTTL check is 117 performed only if any outgoing TTL (either IP or MPLS) is set to 118 oTTL (see section 3.5 for exception). 120 3. TTL Processing in different Models 122 This section describes the TTL processing for LSPs conforming to 123 each of the 3 models (Uniform, Short Pipe and Pipe) in the 124 presence/absence of PHP (where applicable). 126 3.1. TTL Processing for Uniform Model LSPs (with or without PHP) 128 (consistent with [MPLS-ENCAPS]): 130 ========== LSP =============================> 132 +--Swap--(n-2)-...-swap--(n-i)---+ 133 / (outer header) \ 134 (n-1) (n-i) 135 / \ 136 >--(n)--Push...............(x).....................Pop--(n-i-1)-> 137 (I) (inner header) (E or P) 139 (n) represents the TTL value in the corresponding header 140 (x) represents non-meaningful TTL information 141 (I) represents the LSP ingress node 142 (P) represents the LSP penultimate node 143 (E) represents the LSP Egress node 145 This picture shows TTL processing for a uniform model MPLS LSP. Note 146 that the inner and outer TTLs of the packets are synchronized at 147 tunnel ingress and egress. 149 3.2. TTL Processing for Short Pipe Model LSPs 151 3.2.1. TTL Processing for Short Pipe Model LSPs without PHP 153 ========== LSP =============================> 155 +--Swap--(N-1)-...-swap--(N-i)-----+ 156 / (outer header) \ 157 (N) (N-i) 158 / \ 159 >--(n)--Push...............(n-1).....................Pop--(n-2)-> 160 (I) (inner header) (E) 162 (N) represents the TTL value (may have no relationship to n) 163 (n) represents the tunneled TTL value in the encapsulated header 164 (I) represents the LSP ingress node 165 (E) represents the LSP Egress node 167 Short Pipe Model was introduced in [MPLS-DS]. In the short pipe 168 model, the forwarding treatment at the egress LSR is based on the 169 tunneled packet as opposed to the encapsulating packet. 171 3.2.2. TTL Processing for Short Pipe Model with PHP: 173 ========== LSP =====================================> 174 +-Swap-(N-1)-...-swap-(N-i)-+ 175 / (outer header) \ 176 (N) (N-i) 177 / \ 178 >--(n)--Push.............(n-1)............Pop-(n-1)-Decr.-(n-2)-> 179 (I) (inner header) (P) (E) 181 (N) represents the TTL value (may have no relationship to n) 182 (n) represents the tunneled TTL value in the encapsulated header 183 (I) represents the LSP ingress node 184 (P) represents the LSP penultimate node 185 (E) represents the LSP egress node. 187 Since the label has already been popped by the LSP's penultimate 188 node, the LSP egress node just decrements the header TTL. 190 Also note that at the end of short pipe model LSP, the TTL of the 191 tunneled packet has been decremented by two either with or without 192 PHP. 194 3.3. TTL Processing for Pipe Model LSPs (without PHP only): 196 ========== LSP =============================> 198 +--Swap--(N-1)-...-swap--(N-i)-----+ 199 / (outer header) \ 200 (N) (N-i) 201 / \ 202 >--(n)--Push...............(n-1)....................Pop--(n-2)-> 203 (I) (inner header) (E) 205 (N) represents the TTL value (may have no relationship to n) 206 (n) represents the tunneled TTL value in the encapsulated header 207 (I) represents the LSP ingress node 208 (E) represents the LSP Egress node 210 From the TTL perspective, the treatment for a Pipe Model LSP is 211 identical to the Short Pipe Model without PHP. 213 3.4. Incoming TTL (iTTL) determination 215 If the incoming packet is an IP packet, then the iTTL is the TTL 216 value of the incoming IP packet. 218 If the incoming packet is a MPLS packet and we are performing a 219 Push/Swap/PHP, then the iTTL is the TTL of the topmost incoming 220 label. 222 If the incoming packet is a MPLS packet and we are performing a Pop 223 (tunnel termination), the iTTL is based on the tunnel type (Pipe or 224 Uniform) of the LSP that was popped. If the popped label belonged to 225 a Pipe model LSP, then the iTTL is the value of the TTL field of the 226 header exposed after the label was popped (note that for the purpose 227 of this draft, the exposed header may be either an IP header or an 228 MPLS label). If the popped label belonged to a Uniform model LSP, 229 then the iTTL is equal to the TTL of the popped label. If multiple 230 Pop operations are performed sequentially, then the procedure given 231 above is repeated with one exception: the iTTL computed during the 232 previous Pop is used as the TTL of subsequent label being popped; 233 i.e. the TTL contained in the subsequent label is essentially 234 ignored and replaced with the iTTL computed during the previous pop. 236 3.5. Outgoing TTL Determination and Packet Processing 238 After the iTTL computation is performed, the oTTL check is performed. 239 If the oTTL check succeeds, then the outgoing TTL of the 240 (labeled/unlabeled) packet is calculated and packet headers are 241 updated as defined below. 243 If the packet was routed as an IP packet, the TTL value of the IP 244 packet is set to oTTL (iTTL - 1). The TTL value(s) for any pushed 245 label(s) are determined as described in section 3.6. 247 For packets that are routed as MPLS, we have four cases: 249 1) Swap-only: The routed label is swapped with another label 250 and the TTL field of the outgoing label is set to oTTL. 252 2) Swap followed by a Push: The swapped operation is performed 253 as described in (1). The TTL value(s) of any pushed label(s) 254 are determined as described in section 3.6. 256 3) Penultimate Hop Pop (PHP): The routed label is popped. The 257 oTTL check should be performed irrespective of whether the 258 oTTL is used to update the TTL field of the outgoing header. 259 If the PHPed label belonged to a short Pipe model LSP, then 260 the TTL field of the PHP exposed header is neither checked 261 nor updated. If the PHPed label was a Uniform model LSP, 262 then the TTL field of the PHP exposed header is set to the 263 oTTL. The TTL value(s) of additional labels are determined 264 as described in section 3.6 266 4) Pop: The pop operation happens before routing and hence it 267 is not considered here. 269 3.6. Tunnel Ingress Processing (Push) 271 For each pushed Uniform model label, the TTL is copied from the 272 label/IP-packet immediately underneath it. 274 For each pushed Pipe model or Short Pipe model label, the TTL field 275 is set to a value configured by the network operator. In most 276 implementations, this value is set to 255 by default. 278 3.7. Implementation Remarks 280 1) Although iTTL can be decremented by a value larger than 1 281 while it is being updated or oTTL is being determined, this 282 feature should be only used for compensating for network 283 nodes that are not capable of decrementing TTL values. 285 2) Whenever iTTL is decremented, the implementer must make sure 286 that the value does not go negative. 288 3) In the short pipe model with PHP enabled, the TTL of the 289 tunneled packet is unchanged after the PHP operation. 291 4. Conclusion 293 This Internet Draft describes how TTL field can be processed in a 294 MPLS network. We clarified the various methods that are applied in 295 the presence of hierarchical tunnels and completed the integration 296 of Pipe and Uniform models with TTL processing. 298 5. Security Considerations 300 This document does not add any new security issues other than the 301 ones defined in [MPLS-ENCAPS, MPLS-DS]. In particular, the document 302 does not define a new protocol or expand an existing one and does 303 not introduce security problems into the existing protocols. The 304 authors believe that clarification of TTL handling in MPLS networks 305 benefits service providers and their customers since troubleshooting 306 is simplified. 308 6. References 310 6.1. Normative References 312 [MPLS-ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol 313 Label Switching Architecture", RFC 3031. 315 [MPLS-ENCAPS] E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. 316 Farinacci, T. Li, A. Conta, "MPLS Label Stack Encoding", RFC3032. 318 [MPLS-DS] F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, 319 R. Krishnan, P. Cheval, J. Heinanen, "MPLS Support of Differentiated 320 Services", RFC3270. 322 6.2. Informative References 324 [MPLS-LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. 325 Thomas, "LDP Specification", RFC 3036. 327 [MPLS-RSVP] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. 328 Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209. 330 7. Acknowledgements 332 The authors would like to thank the members of the MPLS working 333 group for their feedback. We would especially like to thank Shahram 334 Davari and Loa Andersson for their careful review of the document 335 and their comments. 337 8. Author's Addresses 339 Puneet Agarwal 340 Pluris 341 10455 Bandley Drive 342 Cupertino, CA 95014 343 Email: puneet@pluris.com 345 Bora Akyol 346 Cisco Systems 347 170 W. Tasman Drive 348 San Jose, CA 95134 349 Email: bora@cisco.com