[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01                                                         
Expiration Date: August 2001
                                                       Satoru Matsushima
                                                           Japan Telecom
                                                         Ken-ichi Nagami
                                                            Toshiba Corp
                                                             Hideo Ishii
                                                     Asia GlobalCrossing
                                                          Yuichi Ikejiri
                                                      NTT Communications
                                                           February 2001

                 TTL Processing expansion for 1-hop LSP

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-

    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

    The list of Internet-Draft Shadow Directories can be accessed at


    Some MPLS-VPN service provider want to hide their network topology
    from their customers.However, according to [MPLS-ARCH] and [MPLS-
    SHIM], the value of TTL field of IP packets is decreased the amount
    of hop counts on a LSP at an egress LSR.Therefore at this time, It
    is possible that the customer know the number of routers onto a LSP
    of MPLS-VPN service provider.The achievement of of hiding a provider
    netowrk topology, that may sometime be useful for MPLS-VPN service
    operations. The way of 1 TTL decrement method onto a LSP at an egress
    LSR, that is called as "1-hop LSP". This document specifies the
    procedure to decrease the TTL of IP packets for the 1-hop LSP and also
    discusses LSP's keepalive method using the 1-hop LSP.

S.Matsushima et al.                                             [Page 1]

Internet Draft        draft-satoru-mpls-1hop-lsp-00.txt         February 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

      - 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     6
   MPLS TTL          9      8      7

    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.

S.Matsushima et al.                                             [Page 2]

Internet Draft        draft-satoru-mpls-1hop-lsp-00.txt         February 2001

    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.

    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.

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

S.Matsushima et al.                                             [Page 3]

Internet Draft        draft-satoru-mpls-1hop-lsp-00.txt         February 2001

    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

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

4.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 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).

4.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

    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.

5. 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.

S.Matsushima et al.                                             [Page 4]

Internet Draft        draft-satoru-mpls-1hop-lsp-00.txt         February 2001

6. 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.

7. 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.

8. 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
    Computer & Network Development Center, Toshiba Corporation,
    1, Toshiba-cho, Fuchu-shi,
    Tokyo, 183-8511, Japan
    Phone: +81-42-333-2884
    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 5]