Internet DRAFT - draft-agarwal-mpls-ttl

draft-agarwal-mpls-ttl




                                                         Puneet Agarwal
   Internet Draft                                         Bora A. Akyol
   Document: draft-agarwal-mpls-ttl-00.txt                       Pluris
   Category                                               Informational
   Expires: August 2001                                   February 2001
    
    
                      TTL Processing in MPLS Networks 
    
    
Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance 
   with all provisions of Section 10 of RFC2026. 
    
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that      
   other groups may also distribute working documents as Internet-
   Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time.  It is inappropriate to use Internet-Drafts as 
   reference material or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt 
   The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html. 
    
    
Abstract 
    
   This document describes TTL processing in hierarchical MPLS 
   networks. 
    
Conventions used in this document 
    
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
   this document are to be interpreted as described in [RFC-2119]. 
    
1. Introduction and Motivation 
    
   This document describes TTL processing in hierarchical MPLS 
   networks. We believe that this document adds details that have not 
   been addressed in [MPLS-ARCH, MPLS-ENCAPS], and that the methods 
   presented in this document complement [MPLS-DS].  
    
2. TTL Processing in MPLS Networks 
    


                        TTL Processing in MPLS Networks       February 2001 
                                    
    
2.1 Terminology and Background 
    
   As defined in [MPLS-ENCAPS], MPLS packets use a MPLS shim header 
   that indicates the following information about a packet: 
    
   a. MPLS Label (20 bits) 
   b. TTL (8 bits) 
   c. Bottom of stack (1 bit) 
   d. Experimental bits (3 bits) 
    
   The experimental bits were later redefined in [MPLS-DS] to indicate 
   the scheduling and shaping behavior that could be associated with a 
   MPLS packet.  
    
   [MPLS-DS] also defined two models for MPLS tunnel operation: Pipe 
   and Uniform models. In the Pipe model, a MPLS network acts like a 
   conduit when MPLS packets traverse the network such that only the 
   LSP ingress and egress points are visible to nodes that are outside 
   the tunnel. On the other hand, the Uniform model makes all the nodes 
   that a LSP traverses visible to nodes outside the tunnel. We will 
   extend the Pipe and Uniform models to include TTL processing in the 
   following sections. Furthermore, TTL processing when performing 
   Penultimate Hop Pop (PHP) is also described in this document. For a 
   detailed description of Pipe and Uniform models, please see [MPLS-
   DS]. 
    
   TTL processing in MPLS networks can be broken down into two logical 
   blocks: (i) the incoming TTL determination to take into account any 
   tunnel egress due to MPLS Pop operations; (ii) packet processing of 
   (possibly) exposed packet & outgoing TTL.  
    
2.2 New Terminology 
    
   iTTL: The TTL value to use as the incoming TTL. No checks are 
   performed on the iTTL. 
    
   oTTL: This is the TTL value used as the outgoing TTL value. It is 
   always (iTTL _ 1) unless otherwise stated. 
    
   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 
   performed only if any outgoing TTL (either IP or MPLS) is set to 
   oTTL. 
    
 
2.3 Incoming TTL (iTTL) determination 
    
   If the incoming packet is an IP packet, then the iTTL is the TTL 
   value of the incoming IP packet. 
    
   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 
   label. 
                        TTL Processing in MPLS Networks       February 2001 
                                    
    
    
   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 
   Uniform) of the LSP that was popped. If the popped label belonged to 
   a Pipe model LSP, then the iTTL is the TTL of the label/IP-packet 
   exposed after the label was popped. If the popped label belonged to 
   a Uniform model LSP, then the iTTL is equal to the TTL of the popped 
   label. If multiple Pop operations are performed sequentially, then 
   the procedure given above is repeated with one exception: the iTTL 
   computed during the previous Pop is used as the TTL of subsequent 
   label being popped; i.e. the TTL contained in the subsequent label 
   is essentially ignored and replaced with the iTTL computed during 
   the previous pop.  
    
2.4 Outgoing TTL Determination and Packet Processing 
    
        After the iTTL computation is performed, the outgoing TTL of 
        the (labeled) packet is calculated and packet headers are 
        updated. 
          
        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 label(s) are determined as described in section 2.5. 
         
        For packets that are routed as MPLS, we have three cases: 
         
        1) Swap-only: The routed label is swapped with another label 
        and the TTL of the outgoing label is set to oTTL. 
               
        2) Swap followed by a Push: The swapped operation is performed 
        as described in (1). The TTL value(s) of any pushed label(s) 
        are determined as described in section 2.5. 
         
        3) Penultimate Hop Pop (PHP): The routed label is popped. The 
        oTTL check should be performed irrespective of whether the oTTL 
        is used in any outgoing label/IP-header. The oTTL used for the 
        TTL check is the unmodified oTTL (iTTL _1). If the PHPed label 
        belonged to a Pipe model LSP, then the oTTL is set to the TTL 
        of the PHP exposed IP-packet/label - but the TTL of the PHP 
        exposed IP-header/label is NOT updated. If the PHPed label was 
        a Uniform model LSP, then the TTL of the PHP exposed IP-
        header/label is set to the oTTL. The TTL values of additional 
        labels are determined as described in Section 2.5.  
    
2.5 Tunnel Ingress Processing (Push) 
    
   For each pushed Uniform model label, the TTL is copied from the 
   label/IP-packet immediately underneath it.  
    
   For each pushed Pipe model label, the TTL field is set to a value 
   configured by the network operator. In most implementations, this 
   value is set to 255 by default. 
    
                        TTL Processing in MPLS Networks       February 2001 
                                    
    
3. Conclusion 
    
   This Internet Draft describes how TTL field can be processed in a 
   MPLS network. We clarified the various methods that are applied in 
   the presence of hierarchical tunnels and completed the integration 
   of Pipe and Uniform models with TTL processing. 
  
4. Security Considerations 
    
   This document does not add any new security issues other than the 
   ones defined in [MPLS-ENCAPS, MPLS-DS]. 
 
5. References 
    
   [MPLS-ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol 
   Label Switching Architecture," RFC 3031. 
    
   [MPLS-ENCAPS] E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. 
   Farinacci, T. Li, A. Conta, "MPLS Label Stack Encoding," RFC3032. 
    
   [MPLS-DS] F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, 
   R. Krishnan, P. Cheval, J. Heinanen, "MPLS Support of Differentiated 
   Services," draft-ietf-mpls-diff-ext-07.txt. (Work in progress) 
 
Author's Addresses 
    
    
   Puneet Agarwal 
   Pluris 
   10455 Bandley Drive 
   Cupertino, CA 95014 
   Email: puneet@pluris.com  
    
   Bora Akyol 
   Pluris 
   10455 Bandley Drive 
   Cupertino, CA 95014 
   Email: akyol@akyol.org 
    
    
Expiration 
 
This document will expire in August 2001.