draft-ietf-mpls-ttl-04.txt   rfc3443.txt 
Internet Draft Puneet Agarwal Network Working Group P. Agarwal
Brocade Request for Comments: 3443 Brocade
Bora A. Akyol Updates: 3032 B. Akyol
Document: draft-ietf-mpls-ttl-04.txt Cisco Systems Category: Standards Track Cisco Systems
Category: Standards Track January 2003
Expires: May 2003 November 2002
Time to Live (TTL) Processing in MPLS Networks (Updates RFC 3032) Time To Live (TTL) Processing in
Multi-Protocol Label Switching (MPLS) Networks
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document specifies an Internet standards track protocol for the
with all provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six Copyright Notice
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 Copyright (C) The Internet Society (2003). All Rights Reserved.
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 Abstract
This document describes TTL processing in hierarchical MPLS networks This document describes Time To Live (TTL) processing in hierarchical
and is motivated by the need to formalize a TTL-transparent mode of Multi-Protocol Label Switching (MPLS) networks and is motivated by
operation for an MPLS label-switched path. It updates RFC-3032 "MPLS the need to formalize a TTL-transparent mode of operation for an MPLS
Label Stack Encoding". TTL processing in both pipe and uniform model label-switched path. It updates RFC 3032, "MPLS Label Stack
Encoding". TTL processing in both Pipe and Uniform Model
hierarchical tunnels are specified with examples for both "push" and hierarchical tunnels are specified with examples for both "push" and
"pop" cases. The document also complements RFC-3270 "MPLS Support of "pop" cases. The document also complements RFC 3270, "MPLS Support
Differentiated Services" and ties together the terminology of Differentiated Services" and ties together the terminology
introduced in that document with TTL processing in hierarchical MPLS introduced in that document with TTL processing in hierarchical MPLS
networks. 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
this document are to be interpreted as described in [RFC-2119]. document are to be interpreted as described in [RFC-2119].
Agarwal & Akyol draft-ietf-mpls-ttl-04.txt 1
Time to Live (TTL) Processing in MPLS Networks November 2002
1. Introduction and Motivation 1. Introduction and Motivation
This document describes Time to Live (TTL) processing in This document describes Time To Live (TTL) processing in hierarchical
hierarchical MPLS networks. We believe that this document adds MPLS networks. We believe that this document adds details that have
details that have not been addressed in [MPLS-ARCH, MPLS-ENCAPS], not been addressed in [MPLS-ARCH, MPLS-ENCAPS], and that the methods
and that the methods presented in this document complement [MPLS- presented in this document complement [MPLS-DS].
DS].
In particular, a new mode of operation (referred to as the pipe In particular, a new mode of operation (referred to as the Pipe
model) is introduced to support the practice of configuring MPLS Model) is introduced to support the practice of configuring MPLS LSPs
LSPs such that packets transiting that LSP see the tunnel as a such that packets transiting the LSP see the tunnel as a single hop
single hop regardless of the number of intermediary label switch regardless of the number of intermediary label switch routers (LSR).
routers (LSR). The pipe model for TTL is currently being used in The Pipe Model for TTL is currently being used in multiple networks
multiple networks and is provided as an option configurable by the and is provided as an option configurable by the network operator by
network operator by several vendors. several vendors.
This document formalizes the TTL processing in MPLS networks and This document formalizes the TTL processing in MPLS networks and ties
ties it with the terminology introduced in [MPLS-DS]. it with the terminology introduced in [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
address the Pipe Model or the Short Pipe Model. This draft the Pipe Model or the Short Pipe Model. This document addresses
addresses these 2 models and for completeness will also these two models and for completeness will also address the
address the Uniform Model. Uniform Model.
b) [MPLS-ENCAPS] does not cover hierarchical LSPs. This draft
b) [MPLS-ENCAPS] does not cover hierarchical LSPs. This document
addresses this issue. addresses this issue.
c) [MPLS-ENCAPS] does not define TTL processing in the presence
of Penultimate Hop Popping (PHP). This draft addresses this c) [MPLS-ENCAPS] does not define TTL processing in the presence of
Penultimate Hop Popping (PHP). This document addresses this
issue. issue.
2.2. Terminology and Background 2.2. Terminology and Background
As defined in [MPLS-ENCAPS], MPLS packets use a MPLS shim header As defined in [MPLS-ENCAPS], MPLS packets use a MPLS shim header that
that indicates the following information about a packet: indicates the following information about a packet:
a. MPLS Label (20 bits) a) MPLS Label (20 bits)
b. TTL (8 bits) b) TTL (8 bits)
c. Bottom of stack (1 bit) c) Bottom of stack (1 bit)
d. Experimental bits (3 bits) d) Experimental bits (3 bits)
The experimental bits were later redefined in [MPLS-DS] to indicate The experimental bits were later redefined in [MPLS-DS] to indicate
the scheduling and shaping behavior that could be associated with a the scheduling and shaping behavior that could be associated with an
MPLS packet. MPLS packet.
[MPLS-DS] also defined two models for MPLS tunnel operation: Pipe [MPLS-DS] also defined two models for MPLS tunnel operation: Pipe and
and Uniform models. In the Pipe model, a MPLS network acts like a 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
LSP ingress and egress points are visible to nodes that are outside ingress and egress points are visible to nodes that are outside the
tunnel. A Short variation of the Pipe Model is also defined in
Agarwal & Akyol draft-ietf-mpls-ttl-04.txt 2
Time to Live (TTL) Processing in MPLS Networks November 2002
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
PHP is also described in this document. For a detailed description PHP, is also described in this document. For a detailed description
of Pipe and Uniform models, please see [MPLS-DS]. of Pipe and Uniform Models, please see [MPLS-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
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 packets and outgoing TTLs.
We also note here that signaling the LSP type (pipe, short pipe or We also note here that signaling the LSP type (Pipe, Short Pipe or
uniform model) is out of the scope of this document, and that is Uniform Model) is out of the scope of this document, and that is also
also not addressed in the current versions of the label distribution not addressed in the current versions of the label distribution
protocols, e.g. LDP [MPLS-LDP] and RSVP-TE [MPLS-RSVP]. Currently, protocols, e.g. LDP [MPLS-LDP] and RSVP-TE [MPLS-RSVP]. Currently,
the LSP type is configured by the network operator manually by means the LSP type is configured by the network operator manually by means
of either a command line or network management interface. of either a command line or network management interface.
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
oTTL (see section 3.5 for exception). (see section 3.5 for exception).
3. TTL Processing in different Models 3. TTL Processing in different Models
This section describes the TTL processing for LSPs conforming to This section describes the TTL processing for LSPs conforming to each
each of the 3 models (Uniform, Short Pipe and Pipe) in the of the 3 models (Uniform, Short Pipe and Pipe) in the
presence/absence of PHP (where applicable). presence/absence of PHP (where applicable).
Agarwal & Akyol draft-ietf-mpls-ttl-04.txt 3
Time to Live (TTL) Processing in MPLS Networks November 2002
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 TTL 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.
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)-----+
skipping to change at line 192 skipping to change at page 4, line 46
(N) (N-i) (N) (N-i)
/ \ / \
>--(n)--Push...............(n-1).....................Pop--(n-2)-> >--(n)--Push...............(n-1).....................Pop--(n-2)->
(I) (inner header) (E) (I) (inner header) (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
(E) represents the LSP Egress node (E) represents the LSP Egress node
Short Pipe Model was introduced in [MPLS-DS]. In the short pipe The Short Pipe Model was introduced in [MPLS-DS]. In the Short Pipe
model, the forwarding treatment at the egress LSR is based on the Model, the forwarding treatment at the egress LSR is based on the
tunneled packet as opposed to the encapsulating packet. tunneled packet, as opposed to the encapsulating packet.
Agarwal & Akyol draft-ietf-mpls-ttl-04.txt 4
Time to Live (TTL) Processing in MPLS Networks November 2002
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 been popped by the LSP's penultimate Since the label has already been popped by the LSP's penultimate
node, 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 the 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, with or without PHP.
PHP.
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)
/ \ / \
>--(n)--Push...............(n-1)....................Pop--(n-2)-> >--(n)--Push...............(n-1)....................Pop--(n-2)->
skipping to change at line 246 skipping to change at page 6, line 10
(E) represents the LSP Egress node (E) represents the LSP Egress node
From the TTL perspective, the treatment for a Pipe Model LSP is From the TTL perspective, the treatment for a Pipe Model LSP is
identical to the Short Pipe Model without PHP. identical to the Short Pipe Model without PHP.
3.4. Incoming TTL (iTTL) determination 3.4. Incoming TTL (iTTL) determination
If the incoming packet is an IP packet, then the iTTL is the TTL If the incoming packet is an IP packet, then the iTTL is the TTL
value of the incoming IP packet. value of the incoming IP packet.
If the incoming packet is a MPLS packet and we are performing a If the incoming packet is an MPLS packet and we are performing a
Push/Swap/PHP, then the iTTL is the TTL of the topmost incoming Push/Swap/PHP, then the iTTL is the TTL of the topmost incoming
label. label.
Agarwal & Akyol draft-ietf-mpls-ttl-04.txt 5 If the incoming packet is an MPLS packet and we are performing a Pop
Time to Live (TTL) Processing in MPLS Networks November 2002
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 (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 Uniform) of the LSP that was popped. If the popped label belonged to
a Pipe model LSP, then the iTTL is the value of the TTL field of the a Pipe Model LSP, then the iTTL is the value of the TTL field of the
header exposed after the label was popped (note that for the purpose header, exposed after the label was popped (note that for the purpose
of this draft, the exposed header may be either an IP header or an of this document, the exposed header may be either an IP header or an
MPLS label). If the popped label belonged to a Uniform model LSP, MPLS label). If the popped label belonged to a Uniform Model LSP,
then the iTTL is equal to the TTL of the popped label. If multiple then the iTTL is equal to the TTL of the popped label. If multiple
Pop operations are performed sequentially, then the procedure given Pop operations are performed sequentially, then the procedure given
above is repeated with one exception: the iTTL computed during the above is repeated with one exception: the iTTL computed during the
previous Pop is used as the TTL of subsequent label being popped; previous Pop is used as the TTL of subsequent labels being popped;
i.e. the TTL contained in the subsequent label is essentially i.e. the TTL contained in the subsequent label is essentially ignored
ignored and replaced with the iTTL computed during the previous pop. 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.
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) is 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
and the TTL field of the outgoing label is set to oTTL. TTL field of the outgoing label is set to oTTL.
2) Swap followed by a Push: The swapped operation is performed 2) Swap followed by a Push: The swapped operation is performed as
as described in (1). The TTL value(s) of any pushed label(s) described in (1). The TTL value(s) of any pushed label(s) is
are determined as described in section 3.6. determined as described in section 3.6.
3) Penultimate Hop Pop (PHP): The routed label is popped. The 3) Penultimate Hop Pop (PHP): The routed label is popped. The oTTL
oTTL check should be performed irrespective of whether the check should be performed irrespective of whether the oTTL is used
oTTL is used to update the TTL field of the outgoing header. to update the TTL field of the outgoing header. If the PHPed
If the PHPed label belonged to a short Pipe model LSP, then label belonged to a Short Pipe Model LSP, then the TTL field of
the TTL field of the PHP exposed header is neither checked the PHP exposed header is neither checked nor updated. If the
nor updated. If the PHPed label was a Uniform model LSP, PHPed label was a Uniform Model LSP, then the TTL field of the PHP
then the TTL field of the PHP exposed header is set to the exposed header is set to the oTTL. The TTL value(s) of additional
oTTL. The TTL value(s) of additional labels are determined labels are determined as described in section 3.6
as described in section 3.6
4) Pop: The pop operation happens before routing and hence it 4) Pop: The pop operation happens before routing and hence it is not
is not considered here. considered here.
3.6. Tunnel Ingress Processing (Push) 3.6. Tunnel Ingress Processing (Push)
For each pushed Uniform model label, the TTL is copied from the For each pushed Uniform Model label, the TTL is copied from the
label/IP-packet immediately underneath it. label/IP-packet immediately underneath it.
Agarwal & Akyol draft-ietf-mpls-ttl-04.txt 6 For each pushed Pipe Model or Short Pipe Model label, the TTL field
Time to Live (TTL) Processing in MPLS Networks November 2002
For each pushed Pipe model or Short Pipe model label, the TTL field
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
while it is being updated or oTTL is being determined, this is being updated or oTTL is being determined, this feature should
feature should be only used for compensating for network be only used for compensating for network nodes that are not
nodes that are not capable of decrementing TTL values. capable of decrementing TTL values.
2) Whenever iTTL is decremented, the implementer must make sure 2) Whenever iTTL is decremented, the implementer must make sure that
that the value does not go negative. the value does not become 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
tunneled packet is unchanged after the PHP operation. packet is unchanged after the PHP operation.
4. Conclusion 4. Conclusion
This Internet Draft describes how TTL field can be processed in a This Internet Document describes how the TTL field can be processed
MPLS network. We clarified the various methods that are applied in in an MPLS network. We clarified the various methods that are
the presence of hierarchical tunnels and completed the integration applied in the presence of hierarchical tunnels and completed the
of Pipe and Uniform models with TTL processing. integration of Pipe and Uniform Models with TTL processing.
5. Security Considerations 5. Security Considerations
This document does not add any new security issues other than the This document does not add any new security issues other than the
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
not introduce security problems into the existing protocols. The introduce security problems into the existing protocols. The authors
authors believe that clarification of TTL handling in MPLS networks believe that clarification of TTL handling in MPLS networks benefits
benefits service providers and their customers since troubleshooting service providers and their customers since troubleshooting is
is simplified. simplified.
Agarwal & Akyol draft-ietf-mpls-ttl-04.txt 7
Time to Live (TTL) Processing in MPLS Networks November 2002
6. References 6. References
6.1. Normative References 6.1. Normative References
[MPLS-ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol [RFC-2119] Bradner, S. "Key words for use in RFC's to Indicate
Label Switching Architecture", RFC 3031. Requirement Levels", BCP 14, RFC 2119, March 1997.
[MPLS-ENCAPS] E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. [MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon,
Farinacci, T. Li, A. Conta, "MPLS Label Stack Encoding", RFC3032. "Multiprotocol Label Switching Architecture", RFC 3031,
January 2001.
[MPLS-DS] F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, [MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
R. Krishnan, P. Cheval, J. Heinanen, "MPLS Support of Differentiated Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack
Services", RFC3270. Encoding", RFC 3032, January 2001.
[MPLS-DS] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
Vaananen, P., Krishnan, R., Cheval, P. and J. Heinanen,
"Multi-Protocol Label Switching (MPLS) Support of
Differentiated Services", RFC 3270, May 2002.
6.2. Informative References 6.2. Informative References
[MPLS-LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. [MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A.
Thomas, "LDP Specification", RFC 3036. and B. Thomas, "LDP Specification", RFC 3036, January
2001.
[MPLS-RSVP] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. [MPLS-RSVP] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209. V. and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank the members of the MPLS working The authors would like to thank the members of the MPLS working group
group for their feedback. We would especially like to thank Shahram for their feedback. We would especially like to thank Shahram Davari
Davari and Loa Andersson for their careful review of the document and Loa Andersson for their careful review of the document and their
and their comments. comments.
8. Author's Addresses 8. Author's Addresses
Puneet Agarwal Puneet Agarwal
Brocade Communications Systems, Inc. Brocade Communications Systems, Inc.
1745 Technology Drive 1745 Technology Drive
San Jose, CA 95110 San Jose, CA 95110
Email: puneet@acm.org
EMail: puneet@acm.org
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
Agarwal & Akyol draft-ietf-mpls-ttl-04.txt 8 EMail: bora@cisco.com
9. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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