idnits 2.17.1 draft-agarwal-mpls-ttl-01.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 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (October 2001) is 8226 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 41, but not defined Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 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-agarwal-mpls-ttl-01.txt Cisco Systems 6 Category Informational 7 Expires: April 2002 October 2001 9 TTL Processing in MPLS Networks 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. 36 Conventions used in this document 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 40 this document are to be interpreted as described in [RFC-2119]. 42 1. Introduction and Motivation 44 This document describes TTL processing in hierarchical MPLS 45 networks. We believe that this document adds details that have not 46 been addressed in [MPLS-ARCH, MPLS-ENCAPS], and that the methods 47 presented in this document complement [MPLS-DS]. 49 TTL Processing in MPLS Networks October 2001 51 2. Changes from version-00 of draft 53 Based on the feedback on the -00 version of the draft (including the 54 presentation at IETF-50), the following changes have been 55 incorporated in this draft: 57 (a) Added a section to state how the draft enhances previously 58 published RFCs, modifies the functionality specified in the 59 RFCs, adds new functionality not specified in the RFCs and adds 60 details to clarify what is specified in the RFCs 61 (b) Added a statement that signaling the TTL mode is out of the 62 scope of this Internet Draft 63 (c) Clarified that iTTL can be decremented by a value greater than 64 1 (depending on configuration) 65 (d) Clarified that iTTL should be >=N before decrementing by N 66 (e) Cleared the confusion caused by the use of the term "IP 67 Header/Label" by replacing with the more generic term "header" 69 (f) Took out unneeded text in section 4.5 70 (g) Update the terminology for Pipe, Short Pipe and Uniform based 71 on draft-ietf-mpls-diff-ext-09.txt (instead of the -07 version) 73 (h) Add a separate section to visually describe the TTL processing 74 in the above 3 modes (incorporate the pictures from the slides) 76 3. TTL Processing in MPLS Networks 77 3.1. Changes to RFC 3032 [MPLS-ENCAPS] 78 a) [MPLS-ENCAPS] only covers the Uniform Model and does NOT 79 address the Pipe Model or the Short Pipe Model. This draft 80 will address these 2 models and for completeness will also 81 address the Uniform Model. 82 b) [MPLS-ENCAPS] does not cover hierarchical LSPs. This draft 83 will address this issue. 84 c) [MPLS-ENCAPS] does not define TTL processing in the presence 85 of Penultimate Hop Popping (PHP). This draft will address 86 this issue. 88 3.2. Terminology and Background 90 As defined in [MPLS-ENCAPS], MPLS packets use a MPLS shim header 91 that indicates the following information about a packet: 93 a. MPLS Label (20 bits) 94 b. TTL (8 bits) 95 c. Bottom of stack (1 bit) 96 d. Experimental bits (3 bits) 98 The experimental bits were later redefined in [MPLS-DS] to indicate 99 the scheduling and shaping behavior that could be associated with a 100 MPLS packet. 102 TTL Processing in MPLS Networks October 2001 104 [MPLS-DS] also defined two models for MPLS tunnel operation: Pipe 105 and Uniform models. In the Pipe model, a MPLS network acts like a 106 conduit when MPLS packets traverse the network such that only the 107 LSP ingress and egress points are visible to nodes that are outside 108 the tunnel. A "short" variation of the Pipe Model is also defined in 109 [MPLS-DS] to differentiate between different egress forwarding and 110 QoS treatments. On the other hand, the Uniform model makes all the 111 nodes that a LSP traverses visible to nodes outside the tunnel. We 112 will extend the Pipe and Uniform models to include TTL processing in 113 the following sections. Furthermore, TTL processing when performing 114 Penultimate Hop Pop (PHP) is also described in this document. For a 115 detailed description of Pipe and Uniform models, please see [MPLS- 116 DS]. 118 TTL processing in MPLS networks can be broken down into two logical 119 blocks: (i) the incoming TTL determination to take into account any 120 tunnel egress due to MPLS Pop operations; (ii) packet processing of 121 (possibly) exposed packet & outgoing TTL. 123 We also note here that signaling treatment for TTL behavior using 124 either RSVP-TE or LDP is out of the scope of this document. 126 3.3. New Terminology 128 iTTL: The TTL value to use as the incoming TTL. No checks are 129 performed on the iTTL. 131 oTTL: This is the TTL value used as the outgoing TTL value. It is 132 always (iTTL - 1) unless otherwise stated. 134 oTTL Check: Check if oTTL is greater than 0. If the oTTL Check is 135 false, then the packet is not forwarded. Note that the oTTL check is 136 performed only if any outgoing TTL (either IP or MPLS) is set to 137 oTTL. 139 4. TTL Processing in different Models 141 This sections describes the TTL processing for LSPs conforming to 142 each of the 3 models (Uniform, Short Pipe and Pipe) in the 143 presence/absence of PHP (where applicable) 144 TTL Processing in MPLS Networks October 2001 146 4.1. TTL Processing for Uniform Model LSPs (with or without PHP) 148 (consistent with [MPLS-ENCAPS]): 150 ========== LSP =============================> 152 +--Swap--(n-2)-...-swap--(n-i)---+ 153 / (outer header) \ 154 (n-1) (n-i) 155 / \ 156 >--(n)--Push...............(x).....................Pop--(n-i-1)-> 157 (I) (inner header) (E or P) 159 (n) represents the TTL value in the corresponding header 160 (x) represents non-meaningful TLL information 161 (I) represents the LSP ingress node 162 (P) represents the LSP penultimate node 163 (E) represents the LSP Egress node 165 This picture shows TTL processing for a uniform model MPLS LSP. Note 166 that the inner and outer TTLs of the packets are synchronized at 167 tunnel ingress and egress. 169 4.2. TTL Processing for Short Pipe Model LSPs 171 4.2.1. TTL Processing for Short Pipe Model LSPs without PHP 173 ========== LSP =============================> 175 +--Swap--(N-1)-...-swap--(N-i)-----+ 176 / (outer header) \ 177 (N) (N-i) 178 / \ 179 >--(n)--Push...............(n-1).....................Pop--(n-2)-> 180 (I) (inner header) (E) 182 (N) represents the TTL value (may have no relationship to n) 183 (n) represents the tunneled TTL value in the encapsulated header 184 (I) represents the LSP ingress node 185 (E) represents the LSP Egress node 187 Short Pipe Model was introduced in [MPLS-DS]. In the short pipe 188 model, the forwarding treatment at the egress LSR is based on the 189 tunneled packet as opposed to the encapsulating packet. 191 TTL Processing in MPLS Networks October 2001 193 4.2.2. TTL Processing for Short Pipe Model with PHP: 194 ========== LSP =====================================> 195 +-Swap--(N-1)-..-swap--(N-i)-+ 196 / (outer header) \ 197 (N) (N-i) 198 / \ 199 >--(n)--Push.............(n-1)..............Pop-(n-1)-(E)-(n-2)-> 200 (I) (inner header) (P) 202 (N) represents the TTL value (may have no relationship to n) 203 (n) represents the tunneled TTL value in the encapsulated header 204 (I) represents the LSP ingress node 205 (P) represents the LSP penultimate node 206 (E) represents the LSP Egress node 208 Note that at the end of short pipe model LSP the TTL of the tunneled 209 packet has been decremented by two either with or without PHP. 211 4.3. TTL Processing for Pipe Model LSPs (without PHP only): 213 ========== LSP =============================> 215 +--Swap--(N-1)-...-swap--(N-i)-----+ 216 / (outer header) \ 217 (N) (N-i) 218 / \ 219 >--(n)--Push...............(n-1)....................Pop--(n-2)-> 220 (I) (inner header) (E) 222 (N) represents the TTL value (may have no relationship to n) 223 (n) represents the tunneled TTL value in the encapsulated header 224 (I) represents the LSP ingress node 225 (E) represents the LSP Egress node 227 From the TTL perspective, the treatment for a Pipe Model LSP is 228 identical to the Short Pipe Model without PHP. 230 4.4. Incoming TTL (iTTL) determination 232 If the incoming packet is an IP packet, then the iTTL is the TTL 233 value of the incoming IP packet. 235 If the incoming packet is a MPLS packet and we are performing a 236 Push/Swap/PHP, then the iTTL is the TTL of the topmost incoming 237 label. 239 If the incoming packet is a MPLS packet and we are performing a Pop 240 (tunnel termination), the iTTL is based on the tunnel type (Pipe or 241 Uniform) of the LSP that was popped. If the popped label belonged to 242 a Pipe model LSP, then the iTTL is the value of the TTL field of the 243 TTL Processing in MPLS Networks October 2001 245 header exposed after the label was popped (note that for the purpose 246 of this draft, the exposed header may be either an IP header or an 247 MPLS label). If the popped label belonged to a Uniform model LSP, 248 then the iTTL is equal to the TTL of the popped label. If multiple 249 Pop operations are performed sequentially, then the procedure given 250 above is repeated with one exception: the iTTL computed during the 251 previous Pop is used as the TTL of subsequent label being popped; 252 i.e. the TTL contained in the subsequent label is essentially 253 ignored and replaced with the iTTL computed during the previous pop. 255 4.5. Outgoing TTL Determination and Packet Processing 257 After the iTTL computation is performed, the oTTL check is performed. 258 If the oTTL check succeeds, then the outgoing TTL of the 259 (labeled/unlabeled) packet is calculated and packet headers are 260 updated as defined below. 262 If the packet was routed as an IP packet, the TTL value of the IP 263 packet is set to oTTL (iTTL - 1). The TTL value(s) for any pushed 264 label(s) are determined as described in section 4.6. 266 For packets that are routed as MPLS, we have four cases: 268 1) Swap-only: The routed label is swapped with another label 269 and the TTL field of the outgoing label is set to oTTL. 271 2) Swap followed by a Push: The swapped operation is performed 272 as described in (1). The TTL value(s) of any pushed label(s) 273 are determined as described in section 4.6. 275 3) Penultimate Hop Pop (PHP): The routed label is popped. The 276 oTTL check should be performed irrespective of whether the oTTL 277 is used to update the TTL field of the outgoing header. If the 278 PHPed label belonged to a short Pipe model LSP, then the TTL 279 field of the PHP exposed header is neither checked nor 280 updated. If the PHPed label was a Uniform model LSP, then the 281 TTL field of the PHP exposed header is set to the oTTL. The TTL 282 value(s) of additional labels are determined as described in 283 section 4.6 285 4) Pop: The pop operation happens before routing and hence it 286 is not considered here. 288 4.6. Tunnel Ingress Processing (Push) 290 For each pushed Uniform model label, the TTL is copied from the 291 label/IP-packet immediately underneath it. 293 For each pushed Pipe model or Short Pipe model label, the TTL field 294 is set to a value configured by the network operator. In most 295 implementations, this value is set to 255 by default. 297 TTL Processing in MPLS Networks October 2001 299 4.7. Implementation Remarks 301 1) Although iTTL can be decremented by a value larger 302 than 1 while it is being updated or oTTL is being 303 determined, this feature should be only used for 304 compensating for network nodes that are not capable of 305 decrementing TTL values such as OXCs. 306 2) Whenever iTTL is decremented, the implementor must 307 make sure that the value does not go negative. 308 3) In the short pipe model with PHP enabled, the TTL of 309 the tunneled packet is unchanged after the PHP 310 operation. 311 5. Conclusion 313 This Internet Draft describes how TTL field can be processed in a 314 MPLS network. We clarified the various methods that are applied in 315 the presence of hierarchical tunnels and completed the integration 316 of Pipe and Uniform models with TTL processing. 318 TTL Processing in MPLS Networks October 2001 320 6. Security Considerations 322 This document does not add any new security issues other than the 323 ones defined in [MPLS-ENCAPS, MPLS-DS]. 325 TTL Processing in MPLS Networks October 2001 327 7. References 329 [MPLS-ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol 330 Label Switching Architecture," RFC 3031. 332 [MPLS-ENCAPS] E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. 333 Farinacci, T. Li, A. Conta, "MPLS Label Stack Encoding," RFC3032. 335 [MPLS-DS] F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, 336 R. Krishnan, P. Cheval, J. Heinanen, "MPLS Support of Differentiated 337 Services," draft-ietf-mpls-diff-ext-09.txt. (Work in progress) 339 8. Author's Addresses 341 Puneet Agarwal 342 Pluris 343 10455 Bandley Drive 344 Cupertino, CA 95014 345 Email: puneet@pluris.com 347 Bora Akyol 348 Cisco Systems 349 170 W. Tasman Drive 350 San Jose, CA 95134 351 Email: bora@cisco.com