INTERNET-DRAFT 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- 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 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 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 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 coexist. 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 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. 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]