doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc3443.txt b/doc/rfc/rfc3443.txt
new file mode 100644
index 0000000..d2d7a0d
--- /dev/null
+++ b/doc/rfc/rfc3443.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                         P. Agarwal
+Request for Comments: 3443                                       Brocade
+Updates: 3032                                                   B. Akyol
+Category: Standards Track                                  Cisco Systems
+                                                            January 2003
+
+
+                   Time To Live (TTL) Processing in
+             Multi-Protocol Label Switching (MPLS) Networks
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document describes Time To Live (TTL) processing in hierarchical
+   Multi-Protocol Label Switching (MPLS) networks and is motivated by
+   the need to formalize a TTL-transparent mode of operation for an MPLS
+   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
+   "pop" cases.  The document also complements RFC 3270, "MPLS Support
+   of Differentiated Services" and ties together the terminology
+   introduced in that document with 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 Time To Live (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].
+
+
+
+
+Agarwal & Akyol             Standards Track                     [Page 1]
+
+RFC 3443            TTL Processing in MPLS Networks         January 2003
+
+
+   In particular, a new mode of operation (referred to as the Pipe
+   Model) is introduced to support the practice of configuring MPLS LSPs
+   such that packets transiting the LSP see the tunnel as a single hop
+   regardless of the number of intermediary label switch routers (LSR).
+   The Pipe Model for TTL is currently being used in multiple networks
+   and is provided as an option configurable by the network operator by
+   several vendors.
+
+   This document formalizes the TTL processing in MPLS networks and ties
+   it with the terminology introduced in [MPLS-DS].
+
+2. TTL Processing in MPLS Networks
+
+2.1. Changes to RFC 3032 [MPLS-ENCAPS]
+
+   a) [MPLS-ENCAPS] only covers the Uniform Model and does NOT address
+      the Pipe Model or the Short Pipe Model.  This document addresses
+      these two models and for completeness will also address the
+      Uniform Model.
+
+   b) [MPLS-ENCAPS] does not cover hierarchical LSPs.  This document
+      addresses this issue.
+
+   c) [MPLS-ENCAPS] does not define TTL processing in the presence of
+      Penultimate Hop Popping (PHP).  This document addresses this
+      issue.
+
+2.2. 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 an
+   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
+   circuit when MPLS packets traverse the network such that only the LSP
+   ingress and egress points are visible to nodes that are outside the
+   tunnel.  A Short variation of the Pipe Model is also defined in
+   [MPLS-DS] to differentiate between different egress forwarding and
+   QoS treatments.  On the other hand, the Uniform Model makes all the
+
+
+
+Agarwal & Akyol             Standards Track                     [Page 2]
+
+RFC 3443            TTL Processing in MPLS Networks         January 2003
+
+
+   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
+   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 packets and outgoing TTLs.
+
+   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 also
+   not addressed in the current versions of the label distribution
+   protocols, e.g. LDP [MPLS-LDP] and RSVP-TE [MPLS-RSVP].  Currently,
+   the LSP type is configured by the network operator manually by means
+   of either a command line or network management interface.
+
+2.3. 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 (see
+   section 3.5 for exception).  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
+   (see section 3.5 for exception).
+
+3. TTL Processing in different Models
+
+   This section describes the TTL processing for LSPs conforming to each
+   of the 3 models  (Uniform, Short Pipe and Pipe) in the
+   presence/absence of PHP (where applicable).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Agarwal & Akyol             Standards Track                     [Page 3]
+
+RFC 3443            TTL Processing in MPLS Networks         January 2003
+
+
+3.1. TTL Processing for Uniform Model LSPs (with or without PHP)
+
+      (consistent with [MPLS-ENCAPS]):
+
+             ========== LSP =============================>
+
+                 +--Swap--(n-2)-...-swap--(n-i)---+
+                /        (outer header)            \
+              (n-1)                                (n-i)
+              /                                      \
+   >--(n)--Push...............(x).....................Pop--(n-i-1)->
+            (I)           (inner header)            (E or P)
+
+   (n) represents the TTL value in the corresponding header
+   (x) represents non-meaningful TTL information
+   (I) represents the LSP ingress node
+   (P) represents the LSP penultimate node
+   (E) represents the LSP Egress node
+
+   This picture shows TTL processing for a Uniform Model MPLS LSP.  Note
+   that the inner and outer TTLs of the packets are synchronized at
+   tunnel ingress and egress.
+
+3.2. TTL Processing for Short Pipe Model LSPs
+
+3.2.1.     TTL Processing for Short Pipe Model LSPs without PHP
+
+             ========== LSP =============================>
+
+                 +--Swap--(N-1)-...-swap--(N-i)-----+
+                /        (outer header)              \
+              (N)                                  (N-i)
+              /                                        \
+   >--(n)--Push...............(n-1).....................Pop--(n-2)->
+            (I)           (inner header)                (E)
+
+   (N) represents the TTL value (may have no relationship to n)
+   (n) represents the tunneled TTL value in the encapsulated header
+   (I) represents the LSP ingress node
+   (E) represents the LSP Egress node
+
+   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
+   tunneled packet, as opposed to the encapsulating packet.
+
+
+
+
+
+
+
+Agarwal & Akyol             Standards Track                     [Page 4]
+
+RFC 3443            TTL Processing in MPLS Networks         January 2003
+
+
+3.2.2.     TTL Processing for Short Pipe Model with PHP:
+
+             ========== LSP =====================================>
+                 +-Swap-(N-1)-...-swap-(N-i)-+
+                /       (outer header)        \
+              (N)                            (N-i)
+              /                                \
+   >--(n)--Push.............(n-1)............Pop-(n-1)-Decr.-(n-2)->
+            (I)           (inner header)       (P)      (E)
+
+   (N) represents the TTL value (may have no relationship to n)
+   (n) represents the tunneled TTL value in the encapsulated header
+   (I) represents the LSP ingress node
+   (P) represents the LSP penultimate node
+   (E) represents the LSP egress node.
+
+   Since the label has already been popped by the LSP's penultimate
+   node, the LSP egress node just decrements the header TTL.
+
+   Also note that at the end of the Short Pipe Model LSP, the TTL of the
+   tunneled packet has been decremented by two, with or without PHP.
+
+3.3. TTL Processing for Pipe Model LSPs (without PHP only):
+
+             ========== LSP =============================>
+
+                 +--Swap--(N-1)-...-swap--(N-i)-----+
+                /        (outer header)              \
+              (N)                                  (N-i)
+              /                                        \
+   >--(n)--Push...............(n-1)....................Pop--(n-2)->
+            (I)           (inner header)               (E)
+
+   (N) represents the TTL value (may have no relationship to n)
+   (n) represents the tunneled TTL value in the encapsulated header
+   (I) represents the LSP ingress node
+   (E) represents the LSP Egress node
+
+   From the TTL perspective, the treatment for a Pipe Model LSP is
+   identical to the Short Pipe Model without PHP.
+
+
+
+
+
+
+
+
+
+
+
+Agarwal & Akyol             Standards Track                     [Page 5]
+
+RFC 3443            TTL Processing in MPLS Networks         January 2003
+
+
+3.4. 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 an MPLS packet and we are performing a
+   Push/Swap/PHP, then the iTTL is the TTL of the topmost incoming
+   label.
+
+   If the incoming packet is an 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 value of the TTL field of the
+   header, exposed after the label was popped (note that for the purpose
+   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,
+   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 labels being popped;
+   i.e. the TTL contained in the subsequent label is essentially ignored
+   and replaced with the iTTL computed during the previous pop.
+
+3.5. Outgoing TTL Determination and Packet Processing
+
+   After the iTTL computation is performed, the oTTL check is performed.
+   If the oTTL check succeeds, then the outgoing TTL of the
+   (labeled/unlabeled) packet is calculated and packet headers are
+   updated as defined below.
+
+   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) is determined as described in section 3.6.
+
+   For packets that are routed as MPLS, we have four cases:
+
+   1) Swap-only: The routed label is swapped with another label and the
+      TTL field 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) is
+      determined as described in section 3.6.
+
+   3) Penultimate Hop Pop (PHP): The routed label is popped.  The oTTL
+      check should be performed irrespective of whether the oTTL is used
+      to update the TTL field of the outgoing header.  If the PHPed
+      label belonged to a Short Pipe Model LSP, then the TTL field of
+      the PHP exposed header is neither checked nor updated.  If the
+
+
+
+Agarwal & Akyol             Standards Track                     [Page 6]
+
+RFC 3443            TTL Processing in MPLS Networks         January 2003
+
+
+      PHPed label was a Uniform Model LSP, then the TTL field of the PHP
+      exposed header is set to the oTTL.  The TTL value(s) of additional
+      labels are determined as described in section 3.6
+
+   4) Pop: The pop operation happens before routing and hence it is not
+      considered here.
+
+3.6. 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 or Short 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.
+
+3.7. Implementation Remarks
+
+   1) Although iTTL can be decremented by a value larger than 1 while it
+      is being updated or oTTL is being determined, this feature should
+      be only used for compensating for network nodes that are not
+      capable of decrementing TTL values.
+
+   2) Whenever iTTL is decremented, the implementer must make sure that
+      the value does not become negative.
+
+   3) In the Short Pipe Model with PHP enabled, the TTL of the tunneled
+      packet is unchanged after the PHP operation.
+
+4. Conclusion
+
+   This Internet Document describes how the TTL field can be processed
+   in an 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.
+
+5. Security Considerations
+
+   This document does not add any new security issues other than the
+   ones defined in [MPLS-ENCAPS, MPLS-DS].  In particular, the document
+   does not define a new protocol or expand an existing one and does not
+   introduce security problems into the existing protocols.  The authors
+   believe that clarification of TTL handling in MPLS networks benefits
+   service providers and their customers since troubleshooting is
+   simplified.
+
+
+
+
+
+
+Agarwal & Akyol             Standards Track                     [Page 7]
+
+RFC 3443            TTL Processing in MPLS Networks         January 2003
+
+
+6. References
+
+6.1. Normative References
+
+   [RFC-2119]    Bradner, S. "Key words for use in RFC's to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [MPLS-ARCH]   Rosen, E., Viswanathan, A. and  R. Callon,
+                 "Multiprotocol Label Switching Architecture", RFC 3031,
+                 January 2001.
+
+   [MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
+                 Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack
+                 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
+
+   [MPLS-LDP]    Andersson, L., Doolan, P., Feldman, N., Fredette, A.
+                 and B. Thomas, "LDP Specification", RFC 3036, January
+                 2001.
+
+   [MPLS-RSVP]   Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
+                 V. and  G. Swallow, "RSVP-TE: Extensions to RSVP for
+                 LSP Tunnels", RFC 3209, December 2001.
+
+7. Acknowledgements
+
+   The authors would like to thank the members of the MPLS working group
+   for their feedback.  We would especially like to thank Shahram Davari
+   and Loa Andersson for their careful review of the document and their
+   comments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Agarwal & Akyol             Standards Track                     [Page 8]
+
+RFC 3443            TTL Processing in MPLS Networks         January 2003
+
+
+8. Author's Addresses
+
+   Puneet Agarwal
+   Brocade Communications Systems, Inc.
+   1745 Technology Drive
+   San Jose, CA 95110
+
+   EMail: puneet@acm.org
+
+   Bora Akyol
+   Cisco Systems
+   170 W. Tasman Drive
+   San Jose, CA 95134
+
+   EMail: bora@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Agarwal & Akyol             Standards Track                     [Page 9]
+
+RFC 3443            TTL Processing in MPLS Networks         January 2003
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Agarwal & Akyol             Standards Track                    [Page 10]
+