[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01                                                         
INTERNET-DRAFT
Expiration Date: January 2002
                                                       Satoru Matsushima
                                                           Japan Telecom
                                                         Ken-ichi Nagami
                                                            Toshiba Corp
                                                             Hideo Ishii
                                                     Asia GlobalCrossing
                                                          Yuichi Ikejiri
                                                      NTT Communications
                                                               July 2001


                 TTL Processing expansion for 1-hop LSP
                  <draft-satoru-mpls-1hop-lsp-01.txt>



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

   The structure that LSP was handled as 1-hop became necessary. It came
   from the requirement of LSP topology management in the MPLS network.
   As for VPN services using LSP, VPN customers may be confused by
   receiving ICMP packet, e.g., traceroute includes the routers in the
   MPLS backbone un-belonging to the user's VPN topology view, from non
   VPN topology. And ISP may not want to users know the network topology
   because of ISP may want to change the LSP route due to traffic
   engineering purpose. However, according to [MPLS-ARCH] and [MPLS-SHIM]
   does not include such behavior. So, we propose to specify the
   specification to provide "1-hop LSP" that is the way of 1 TTL
   decrement method onto a LSP at an egress LSR. And we also discusses
   LSP's keepalive method using the 1-hop LSP.

S.Matsushima et. al.,                                           [Page 1]


Internet Draft        draft-satoru-mpls-1hop-lsp-01.txt        July 2001



1. Overview

    It is very useful to show 1-hop LSP for IPv4 packet in some
    situations.  However, according to [MPLS-ARCH] and
    [MPLS-SHIM]. basically, LSP can not be shown to 1-hop for IP packet,
    because of the IPv4 TTL is decreased by the amount of hops within
    the MPLS domain. This document specifies the way to realize 1-hop
    LSP which is done by expanded TTL processing of LSRs.

    The 1-hop LSP can be useful in the following situations:

      - If VPN service was provided onto MPLS domain, then the VPN
        providers can hide their backbone network topology from VPN
        customers.

      - LSP was treated as 1-hop path, then LSP can be tunnel deviced.

      - LSP's keepalive can be possible by enabling 1-hop LSP at the LSR.

    To enable 1-hop LSP, the TTL processing is necessary for only in
    ingress and egress LER. However, to do the "Keep-Alive" of the LSP,
    the same level of expansion is required for egress LER on core LSRs.


2. Definition of 1-hop LSP

    The following figure shown an example of 1-hop LSP. There is a 1-hop
    LSP between an ingress LSR (LERi) and egress LSR (LERe). In the
    1-hop LSP, a value of MPLS TTL is decreased at subsequence LSRs. On
    the other hand, a value of IP TTL is set to one less than the
    incoming TTL value at the LERe. The LERe does not set the IP TTL
    value from MPLS TTL value. In this situation, a customer can
    realizes the MPLS network topology as Ra -> LERi -> LERe -> Rb. It
    means that customer does not realize intermediate routers on the
    1-hop LSP.


             Ra -> LERi -> LSR -> LSR -> LERe -> Rb -> Destination
                    |<---- 1-hop LSP ---->|                host/network
   IP TTL    10      9      9      9       8     7
   MPLS TTL          9      8


    In other words, LSP which copes with FEC which corresponds to
    Destination Address is operated with MPLS Domain as 1-hop LSP.


3. Models and methods of 1-hop LSP

    A TTL Processing expansion is given to an ingress LER and an egress
    LER for 1-hop LSP. We have following three cases.


S.Matsushima et. al.,                                           [Page 2]


Internet Draft        draft-satoru-mpls-1hop-lsp-01.txt        July 2001

    (a) Basic process of 1-hop LSP

    When an IP packet is first labeled in ingress LER, the TTL field of
    the label stack entry is set to have the value which could reach an
    egress LER fully. The MPLS-TTL is usually set to have the value of
    255 in most cases.  (The procedure of IP-TTL decrementation is
    assume to be finished before the event of MPLS labelling in the
    ingress LER.)

    The egress LER pops a label and sets IP TTL value to one less than
    that of the received IP packet. The egress LER does not replace the
    value of IP TTL with the incomming MPLS TTL.  As a result, the value
    of IP TTL of the incomming packet at the ingress LER is one less
    than that of the outgoing packet at the egress LER.

    (b) 1-hop LSP with hierarchical labels

    When the LSP with depth m label is set to 1-hop LSP, the LSP provides
    1-hop LSP process to depth m-1 LSP. The TTL process is almost the same
    as the case of (a) except that an IP packet is replaced by a depth m-1
    labeled packet.

    Example:

                      Ra -> LERi -> LSR -> LSR -> LSR(e) -> LSR -> Destination
                              |<--- 1-hop LSP ---->|               host/network
    IP TTL            10      9      9      9      9        9
    MPLS TTL                  255    255    255    254      253    (depth 1)
    MPLS TTL(1-hop LSP)       255    254    253    popped          (depth 2)


    (c) 1-hop LSP with Penultimate Hop Pop (PHP)

    When a label stack may be popped at the penultimate LSR of the
    1-hop LSP, rather than at the LER, the TTL of the exposed label
    or IP is not updated. The process at the egress LER is the same
    as the case of (a) and (b).

    Example:

              Ra -> LERi -> LSR -> LSR -> LERe -> Rb -> Destination
                        |<-- 1-hop LSP ->|                    host/network
    IP TTL    10      9      9      9       8     7
    MPLS TTL          255    254    popped


    This is a fundamental mechanism for making 1-hop LSP, and the model
    which forms 1-hop LSP is divided by the label distribution method;
    DU or DoD.

    In this document, The model which realizes 1-hop with DU is defined
    as "Cloud model", and the model which realizes 1-hop with DoD is
    defined as "Per LSP model". These are explained in the following.


S.Matsushima et. al.,                                           [Page 3]


Internet Draft        draft-satoru-mpls-1hop-lsp-01.txt        July 2001


3.1  Cloud model

    In order to use 1-hop LSP on DU, we must decide whether the whole
    MPLS Cloud shoud be used for 1-hop, or used as just an ordinary
    LSP. This is because, when the LSP set-up is being done on the DU,
    each LSR on the LSP cannot be informed of the characteristics of the
    LSP from the ingress LSR.

    This kind of method is not realistic however. Instead, it will work
    mostly well as 1-hop LSP if "out-going TTL" is defined on BCP such
    that the smaller value of TTL is chosen as the "out-going TTL" by
    comparing the MPLS TTL and the IP TTL on the egress LER where the
    Label is "popped".

    However, in case of the value of the IP TTL being larger than the
    value of MPLS TTL when the Label is "popped", it will not work as
    1-hop LSP.

3.2  Per LSP model

    When LSP set-up is being done on the DoD, each LSR on the LSP can be
    informed of the characteristics of the LSP from the ingress LSR. In
    this case, if the expansion attribute that defines TTL processing
    method is installed, then we can choose between the choice of LSP
    types; one is 1-hop LSP per each LSP, and the other is the ordinary
    LSP. The Orderd Distribution will be needed as well. This is because
    if the ingress LER is not informed by the egress LER of its LER's
    choice of LSP type, there is no way for ingress LER to know if it
    should do the TTL processing on a packet for 1-hop LSP or not.

    The TTL processing method is completely independent of the TTL
    processing methods in other LSPs in Per LSP model due to the open
    choice of TTL processing methods is available in each LSP. (When the
    "LSP merge" which is done with ATM-LSR is made, Per LSP model is not
    applied even if it is DoD.)

    Therefore, basically the Cloud model and the Per LSP model can
    coexist.


4. Applicable Areas of "1-hop LSP"

    This section explains the desirable packets and traffics carried by
    "1-hop LSP", and the types of undesirable packet and traffic carried
    by "1-hop LSP".

    (a) The case where 1-hop LSP shall be applied

        - LSP KeepAlive (See section 5).
        - The case where LSP is layered with "1-hop LSP" exists on its
          higher layer.

    (b) The case where "1-hop LSP" is desirably applied

S.Matsushima et. al.,                                           [Page 4]


Internet Draft        draft-satoru-mpls-1hop-lsp-01.txt        July 2001


        - IP-VPN packets, such as [MPLS-VPN].
          (It would be applied by motivation that is described in
          Section 1. But some Layer2-VPN is excluded from this case.)


    (c) The case where "1-hop LSP" shall not be applied

        - The packets that test the carry-way of LSP
          (i.e. "ping" and "traceroute" used by operators)
          If those packets was carried by "1-hop LSP", the purpose
          that test the carry-way of LSP can not be achieved.

    These mean we may not differentiate whether it is "1-hop LSP" or
    not, just  by looking at the unit of LSP. This is because if the aim
    is different, LSP  may have to be "1-hop" or may not have to be
    "1-hop", even if the packets  are carried through the same LSP.
    This causes the LSR must decide whether packets and traffics should
    be activated as "1-hop LSP" or not, by their aims. Incidentally, the
    setting of LSP activation status should be able to be changed for
    operators desired use.


5. The Possible to LSP "KeepAlive" using 1-hop LSP

5.1  Background

    This "LSP KeepAlive" ability is extremely important for the
    applications which use LSP but cannot know the state of LSP itself
    (for instance, consider the situation where BGP/MPLS VPNs [MPLS-VPN]
    are used; they will recognise the network as "available" only if the
    possibility of the IP accessibility to the PE exits, whatever the
    state of the LSP).

5.2  Method of "LSP KeepAlive" process

    The "KeepAlive" of LSP is possible by the use of IP Packet
    transmission to FEC from the ingress LER with the minimum IP TTL
    (minimum value=1) through 1-hop LSP. This is because if there is a
    cut within LSP then there will be no reply.

    In order to carry out "KeepAlive" of LSP, the expansion process is
    also require for the core LSR such that IP TTL will not be replaced
    by MPLS TTL, just like in the egress LER. This is because, if there
    is a cut within LSP the core LSR will "pop" the label. This means
    that the original core LSR will be made to act as an egress LER.

    The reply can be expected from the entire installed, if, such as
    ICMP ECHO is used for setting of the IP Packet in this situation.

    The TTL does not have to, or more precisely, should not have a value
    of 1 for reply. In case of TTL value on the reply message being 1,
    it will go to the opposite side of LSP "KeepAlive" since the LSP is
    a one-way path. This LSP "KeepAlive" cannot be "KeepAlive" for each

S.Matsushima et. al.,                                           [Page 5]


Internet Draft        draft-satoru-mpls-1hop-lsp-01.txt        July 2001

    LSP.

    The TTL value on the LSP KeepAlive's reply message should have large
    enough value. Also, if there is no route for the reply message to
    return, it will look as though the healthy LSP does not exit.

6. Concern

    In The case that the outgoing TTL of a labeled packet is set to the
    maximum value 255 at an ingress LER, it is difficult to detect loops
    in the MPLS cloud, because the value of the IP TTL field is not
    replaced with the outgoing TTL value when a label is popped or the
    resulting label stack is empty.


7. Security Considerations

    This document does not introduce new security issues other than
    those present in the [MPLS-SHIM] and may use the same mechanisms
    proposed for this technology.


8. Acknowledgments

    Thanks to Ikuo Nakagawa, Hiroshi Esaki and JANOG(Japan Network Operators'
    Group) people for their comments.

9. References

    [MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon,
                  "Multiprotocol Label Switching Architecture",
                  RFC 3031, January 2001.

    [MPLS-SHIM] Rosen, E., Rekhter, Y., Tappan, D., Fedorkow, G.,
                  Farinacci, D. and A. Conta, "MPLS Label Stack
                  Encoding", RFC 3032, January 2001.


    [MPLS-VPN] Rosen, E., et. al.,
                "BGP/MPLS VPNs", draft-rosen-rfc2547bis-03.txt,
                March 2001.














S.Matsushima et. al.,                                           [Page 6]


Internet Draft        draft-satoru-mpls-1hop-lsp-01.txt        July 2001



10. Authors' Address:

    Satoru Matsushima
    Japan Telecom
    4-7-1, Hatchobori, Chuo-ku
    Tokyo, 104-8508 Japan
    Phone: +81-3-5540-8214
    Email: satoru@japan-telecom.co.jp

    Ken-ichi Nagami
    Communication Platform Laboratory, R&D Center, Toshiba Corporation
    1, Komukai Toshiba-cho, Saiwai-ku
    Kawasaki, 212-8582, Japan
    Phone: +81-44-549-2230
    EMail: ken.nagami@toshiba.co.jp

    Hideo Ishii
    Asia GlobalCrossing
    4-3-20, Toranomon, Minato-ku
    Tokyo 106-0001 Japan
    Phone: +81-3-5408-1716
    Email:  hishii@gblx.net

    Yuichi Ikejiri
    NTT Communications Corporation
    1-1-6, Uchisaiwai-cho, Chiyoda-ku
    Tokyo 100-8019 Japan
    Phone: +81-3-6700-8540
    Email: ikejiri@ntt.ocn.ne.jp
























S.Matsushima et. al.,                                           [Page 7]