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.
