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]