Internet Draft Internet Draft Sept., 1997 Yasuhiro Katsube (Toshiba) Yoshihiro Ohba (Toshiba) Ken-ichi Nagami (Toshiba) Two Modes of MPLS Explicit Label Distribution Protocol <draft-katsube-mpls-two-ldp-00.txt> Status of this memo This document is an Internet-Draft. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo discusses characteristics of two types of MPLS protocol operations, which we call 'Edge Control' operation and 'Distributed' operation individually, and proposes that these two mode of protocol operations should be specified as the explicit Label Distribution Protocol for the MPLS. 1. Introduction Label Switched Routers (LSRs) can forward L3 packets based on fixed length labels, e.g., VPI/VCI field in ATM cells, as well as conventional packet forwarding based on L3 address information. Each LSR, including edge router and possibly host, should exchange control messages with its neighbors in order that they share the common understanding of the relationship between the attached label (or its equivalent) and the specific packet stream. Katsube et al. Expires March 1998 [Page 1] Internet Draft Two Modes of Explicit LDP Sept. 1997 With regard to the procedure for control message exchange, which are called Label Distribution Protocol, several mechanisms have been proposed[ARISSPEC][FANP][IFMP][TDP]. They are largely classified into two types of operation; one is what we call "Edge Control" operation[ARISSPEC][TDP], and the other is what we call "Distributed" operation[FANP][IFMP]. With regard to the trigger for establishing or releasing LSPs, the Edge Control operations are often understood as Topology- driven approach, while the Distributed operations as Traffic-driven approach. It should be noted that the issue of how the protocol works (either the Edge Control operation or the Distributed operation) is not necessarily coupled with the issue of what the trigger is. Several combinations would be possible instead. This memo outlines two types of explicit label distribution protocols, discusses characteristics of them individually in terms of the trigger for establishing or releasing LSPs as well as the possible granularity level of the LSPs, and proposes that these two modes of operations should be specified as the explicit Label Distribution Protocol for the MPLS. 2. Two Types of Operation for Explicit Label Distribution Protocol 2.1 Edge Control Operation (a) Operational overview In the Edge Control operation, the Label Switched Path (LSP) establishment procedure is initiated by an edge node (an ingress or egress endpoint of the LSP which can be a router or a host) of the MPLS cloud. The initiator transmits MPLS control messages to its neighbor (downstream or upstream depending on the actual procedure) in order to request establishment of the LSP. The control messages convey at least information that specifies stream (e.g., L3 destination address prefix) to be transmitted over the LSP. The information that identifies the label to be used may also be conveyed in the initial message. The LSR that has received the MPLS initial messages from its neighbor checks the validity of the message, memorizing the notified stream information as well as information to identify the corresponding label (which may be determined by the sender side of the initial messages and notified to the receiver side, or determined by the receiver side and notified to the sender side) at the related interface, and possibly transmitting an acknowledgment to the sender of the initial messages. Katsube et al. Expires March 1998 [Page 2] Internet Draft Two Modes of Explicit LDP Sept. 1997 After having successfully processed the received MPLS control messages, the LSR reconstructs and transmits the MPLS control messages further downstream or upstream along the path of the stream to request establishment of the LSP. The messages includes the information about the stream determined originally by the edge node (initiator). The same procedure is performed at every LSR along the path of the stream until the path reaches the node that cannot extend the LSP any more (e.g., another edge node of the MPLS cloud). An edge-to-edge acknowledgment may be returned to the initiator. (b) Triggers for the LSP establishment or release Triggers for the LSP establishment can be, for example, the creation of an L3 forwarding table entry (Topology-driven), or the arrival of any or specific data traffic corresponding to the L3 forwarding table entry (Traffic-driven) at an edge node. Recognition of a group of L3 address prefixes which are reachable through a specific egress edge node can be a trigger for establishment of much aggregated LSPs. Changes of the paths for existing LSPs in response to L3 route changes would be initiated by the LSR which detect the route change regardless of trigger for the initial establishment. The LSR which detects the route change invalidates the old path by transmitting the control message, which is handled and forwarded hop-by-hop toward the edge node for the existing LSP, and creates the new path by transmitting the control message, which is also handled and forwarded hop-by-hop toward the edge node for the new route. Triggers to release the LSPs would be deletion of the L3 forwarding entry, or can be decrease of the data traffic activity corresponding to the L3 forwarding table. (c) Granularity levels of the LSP Edge routers which initiate the LSP establishment procedure determine the definition of the stream (granularity levels of the LSP) to be transmitted over the LSP. The definition of the stream is included in the establishment message and transmitted hop-by-hop along the path of the stream. A variety of granularity levels can be defined by edge routers, e.g., {dst.prefix}, {BGP next hop}, or {OSPF ABR/ASBR}, depending on the role of the edge node (e.g., just an edge of the MPLS cloud, AS border router, or OSPF Area/AS border router). [ARIS] Establishment of LSPs with fine granularity such as {src.IP, dst.IP}, {src.IP, multicast group} would also be possible with the Message Passing operation, which would be traffic-driven or request-driven. But, as described in 2.2, LSPs with this fine granularity can also be handled by the Distributed operation. Katsube et al. Expires March 1998 [Page 3] Internet Draft Two Modes of Explicit LDP Sept. 1997 (d) Other notes The edge-to-edge massage forwarding in this approach enables to associate several related knowledge with the LSP, e.g., hop-count for the LSP can be notified to edge routers, loop detection or prevention for the LSP becomes possible, and completion of the edge-to-edge LSP can be confirmed by the ingress edge router before transmitting data packets over the LSP. Processing burden for protocol state management and message handling becomes much larger than the Distributed operation in the case that frequency of establishment, change or release of LSPs are relatively high (e.g., for traffic-driven fine granularity stream, or for IP multicast stream with frequent group membership changes). 2.2 Distributed Operation (a) Operational overview In the Distributed Operation, the LSP establishment procedure in an MPLS cloud is initiated by individual LSRs (and edge nodes) in a distributed manner. Each of them transmits MPLS control messages to its neighbor (downstream or upstream depending on the actual procedure) in order to share the mapping relationship between a specific stream and the label dedicated to the stream. The messages will convey at least information that specifies stream to be transmitted with the specific label. The information that identifies the label to be used may also be conveyed by the initial message. The LSR that has received the MPLS initial messages from its neighbor checks the validity of the message, memorizing the received stream information as well as the corresponding label information (which may be determined by the sender side of the initial MPLS control messages and notified to the receiver side, or determined by the receiver side and notified to the sender side) at the related interface, and possibly transmitting an acknowledgment to the sender of the initial messages. Unlike the case of the Edge Control operation, exchange of MPLS messages with its neighbor (upstream or downstream) does not trigger exchange of MPLS control messages with its another side of neighbor (upstream or downstream) in an LSR in this case. An MPLS control message exchange for a specific stream between each pair of neighboring LSRs is initiated and carried out independently from the message exchange for the same stream between any other pair of LSRs. Katsube et al. Expires March 1998 [Page 4] Internet Draft Two Modes of Explicit LDP Sept. 1997 (b) Triggers for the LSP establishment or release Triggers for the LSP establishment can be, for example, the arrival of any or specific data traffic (Traffic-driven) at individual LSRs and edge nodes on the path. The common rule with regard to the trigger for the LSP establishment (the condition to initiate the LSP establishment) should be configured to all LSRs and edge nodes in the MPLS cloud in order that the LSPs are successfully established in a distributed manner. The arrival of RSVP Resv messages (Request-driven) at individual LSRs and edge nodes on the path will also be appropriate for the distributed protocol operation. Reception of the Resv message at an LSR from its downstream neighbor triggers the control message exchange with the downstream neighbor (to notify mapping relationship between the stream corresponding to the RSVP flow and the label information to convey the stream), then the LSR transmits the Resv message further upstream. Here we assume the use of current standard RSVP message format with no additional object defined for the MPLS. The same thing applies to the case of multicast with PIM-SM. Reception of PIM Join messages (Request-driven) at an LSR from its downstream neighbor triggers the control message exchange with the downstream neighbor as well as the LSR transmits the PIM Join message further upstream. Here we assume the use of current standard PIM message format with no additional object defined for the MPLS. Changes of the paths for existing LSPs in response to L3 route changes are initiated by the LSR which detect the route change regardless of trigger for the initial establishment. The LSR which detects the route change invalidates the mapping relationship between the label and the stream toward its downstream neighbor by exchanging control messages with it, which however does not trigger the control message transmission toward further downstream nodes. The old path will be released by timeout because of, e.g., no data traffic is emitted to the old path or no Path/Resv message transmitted over the old path. Creation of the new path from the LSR that detect the route change will be carried out in the distributed manner similarly to the initial LSP setup procedure. Triggers to release the LSPs would be, for example, decrease of data traffic activity, or RSVP reservation state expiration at individual LSRs or edge nodes on the path, which keeps principles of distributed operation. (c) Granularity levels of the LSP Definition of the stream should be determined by individual LSRs and edge nodes on the path with their own decision since no such information is conveyed hop-by-hop by the control messages in the Katsube et al. Expires March 1998 [Page 5] Internet Draft Two Modes of Explicit LDP Sept. 1997 Distributed operation. Therefore, the granularity levels provided by the Distributed operation is restricted to the extent that individual LSRs and edge nodes can commonly understand by themselves. In the case of Traffic-driven setup, LSRs and edge nodes on the path can recognize the stream of L3 level end-to-end granularity individually by referring to the data packets (e.g., {src.IP, dst.IP} and {src.IP, multicast group}). In addition, they can recognize the stream of {src.IP, dst.prefix} granularity individually when they are guaranteed to have the forwarding table entry with the same aggregation level given by the routing protocol or by configuration. In the case of Request-driven setup, each of the LSRs can recognize the stream with application to application granularity by referring to the RSVP Resv messages (e.g., {src.IP/port, dst.IP/port}), or recognize the stream with L3 level end-to-end granularity by referring to the PIM Join messages (e.g., {RP, multicast group} or {src.IP, multicast group). As the data packets, the RSVP Resv messages, and the PIM Join messages travel along the path of the LSP with the information of those stream definition, they perform almost the same role as the edge-to-edge Edge Control case, which facilitate the LSP control with the Distributed operation. (d) Other Notes Although no information with edge-to-edge importance can be shared through the Distributed operation, overall procedure is simple and it is easy to follow dynamic changes in router state, e.g., unicast routing, multicast group membership, or RSVP reservation state. Various knowledge related to the LSP such as hop-count, existence of loop cannot be obtained in the Distributed operation. 3. Desirable Protocol Operations for Individual Types of LSPs 3.1 Unicast LSP 3.1.1 Unicast LSP with Arbitrary Granularity Level When the MPLS cloud should provide LSPs for aggregated streams with various granularity levels, the use of Edge Control operation is desirable. The granularity level should be determined by edge nodes (either ingress or egress), then should be notified by MPLS control messages hop-by-hop to all LSRs on the path of the stream. The LSP establishment can be triggered by creation of forwarding table entries (Topology-driven) or the arrival of traffic corresponding Katsube et al. Expires March 1998 [Page 6] Internet Draft Two Modes of Explicit LDP Sept. 1997 to the table entry (Traffic-driven). The release of the LSP can be triggered by the deletion of the forwarding table entries or can be triggered by the decrease of traffic activities corresponding to the table entry. Figure 1 shows examples of a message sequence for unicast LSP setup with the Edge Control operation. The sequences initiated by an ingress edge (like TDP) and the sequence initiated by an egress edge (like ARIS) are shown. Note that the detailed procedure should be specified by the MPLS WG. Ingress======== LSR1 ======== LSR2 ======== LSR3 ========Egress TRG req req req req |-------->++++|-------->++++|-------->++++|-------->++ ack ack ack ack | <--------|++++<--------|++++<--------|++++<--------|++ (i) Ingress Initiated Sequence Ingress======== LSR1 ======== LSR2 ======== LSR3 ========Egress req req req req TRG +<---------|++++<--------|++++<--------|++++<---------| | ack | ack | ack | ack +----------> +---------> +---------> +---------> (ii) Egress Initiated Sequence (TRG = "creation of forwarding entry" or "arrival of data packets") Fig.1 Examples of Message Sequence for Arbitrary Granularity 3.1.2 Unicast LSP with Limited Granularity Level When the MPLS cloud provides unicast LSPs for specific end-to-end L3 streams on-demand (Traffic-driven), it can adopt the Edge Control operation since the end-to-end L3 stream (specified by {src.IP, dst.IP}) is just one of the granularity levels described in 3.1.1. But it should be noted that provision of traffic-driven LSPs for end-to-end L3 streams requires much frequent establishments or releases of LSPs compared with aggregated LSPs. Distributed operation which is more lightweight than Edge Control operation Katsube et al. Expires March 1998 [Page 7] Internet Draft Two Modes of Explicit LDP Sept. 1997 may be preferable in this case. As described in 2.2, it is possible to provide, for example, {src.IP, dst.prefix} level granularity in a domain whose routers share the forwarding entry with the same level of network mask. Figure 2 shows an example of the message sequence for unicast LSP setup with the Distributed operation triggered by data traffic. Note that the detailed procedure should be specified by the MPLS WG. Ingress======== LSR1 ======== LSR2 ======== LSR3 ========Egress packet packet packet packet -> - - - - - -> - - - - - -> - - - - - -> - - - - - -> TRG req TRG req TRG req TRG req |-------->+ |-------->+ |-------->+ |-------->+ ack | ack | ack | ack | <---------+ <---------+ <---------+ <---------+ (TRG = "arrival of data packets") Fig.2 Example of Message Sequence for Fine Granularity 3.2 Multicast LSP When the MPLS cloud provides LSPs along source-based or shared multicast trees, point-to-multipoint LSPs will be established whose origination points are either the ingress edge node closest to the source or the RP for the PIM-SM. The traffic-driven, Distributed operation is straightforward in the case of dense mode protocol such as DVMRP in terms of the initial setup procedure as well as addition or deletion of group members. Triggered by the arrival of multicast packets, each LSR can establish dedicated labels to its downstream neighbors using the Distributed operation. The request-driven, Distributed operation is straightforward in the case of sparse mode protocol such as PIM-SM in terms of initial setup as well as addition or deletion of group members. Triggered by the arrival of PIM Join messages from the downstream neighbors, each LSR can establish dedicated labels to its downstream neighbors using the Distributed operation. Note that inclusion of label information in the PIM Join message may be enough for label establishment in some cases as described in [TAG]. But in the case that the label value is changed between neighboring LSRs as described in [KATSU], inclusion Katsube et al. Expires March 1998 [Page 8] Internet Draft Two Modes of Explicit LDP Sept. 1997 of label information in the PIM Join message alone is not enough but additional message handshake between neighboring LSRs is necessary. Figure 3 and 4 show examples of the message sequence for multicast LSP setup with the Distributed operation in the traffic-driven case and request-driven case individually. Note that the detailed procedure should be specified by the MPLS WG. ack ack ack <---------+ <---------+ <----------+ req | req | req | |-------->+ |-------->+ |--------->+ TRG TRG TRG packet packet packet -> - - - - - -> - - - - - -> - - - - - -> Ingress======== LSR1 ======== LSR2 ========Egress | packet | - - - - - - - - - - - -> +========================Egress req |----------------------->+ ack | <------------------------+ (TRG = "arrival of data packets") Fig.3 Example of Message Sequence for Multicast LSPs (Traffic-driven) ack ack ack <---------+ <---------+ <----------+ req | req | req | |-------->+ |-------->+ |--------->+ TRG TRG TRG PIM Join PIM Join PIM Join <- - - - - <- - - - - <- - - - - Ingress======== LSR1 ======== LSR2 ========Egress | +========================Egress PIM Join <- - - - - - - - - - - - TRG req |----------------------->+ ack | <------------------------+ (TRG = "arrival of PIM Join") Fig.4 Example of Message Sequence for Multicast LSPs (Request-driven) Katsube et al. Expires March 1998 [Page 9] Internet Draft Two Modes of Explicit LDP Sept. 1997 3.3 Unicast/Multicast LSP with RSVP With regard to the LSP establishment in response to the creation of RSVP reservation state (Request-driven), the Edge Control operation initiated by edge nodes does not adequate since each LSR must forward RSVP Resv messages upstream after it succeeds to establish labels toward its downstream neighbors, which requires distributed LSP control operation rather than operation initiated by edge routers. The procedure will almost the same as the case with PIM-SM. Triggered by the arrival of RSVP Resv messages from the downstream neighbors, each LSR would establish dedicated labels to its downstream neighbors using the Distributed operation. Note that the inclusion of label information in the RSVP Resv message may be enough for label establishment in some cases as described in [DAVIE][VISWA]. But in the case that the label value is changed between neighboring LSRs as described in [KATSU], inclusion of label information in the RSVP Resv message alone is not enough but additional message handshake between neighboring LSRs is necessary. Figure 5 shows an example of the message sequence for rsvp-driven LSP setup with the Distributed operation. Note that the detailed procedure should be specified by the MPLS WG. ack ack ack <---------+ <---------+ <----------+ req | req | req | |-------->+ |-------->+ |--------->+ TRG TRG TRG Resv Resv Resv <- - - - - <- - - - - <- - - - - Ingress======== LSR1 ======== LSR2 ========Egress | +========================Egress Resv <- - - - - - - - - - - - TRG req |----------------------->+ ack | <------------------------+ (TRG = "arrival of RSVP Resv message") Fig.5 Example of Message Sequence for LSPs with RSVP (Request-driven) Katsube et al. Expires March 1998 [Page 10] Internet Draft Two Modes of Explicit LDP Sept. 1997 4. Security Consideration Security issues are not discussed in this memo. 5. Conclusion Based on to the discussion above, we propose that the two mode of explicit label distribution protocols, which we call "Massage Passing" operation and "Distributed" operation, should be supported. Either of them would be utilized according to the stream granularity trigger, and configuration (p-p/p-mp) of the LSP. 6. References [ARIS] A.Viswanathan, N.Feldman, R.Biovie, and R. Woundy, "ARIS: Aggregated Route-Based IP Switching", draft-viswanathan-aris-overview-00.txt, March 1997. [ARISSPEC] N. Feldman, A. Viswanathan, "ARIS Specification", draft-feldman-aris-spec-00.txt, March 1997. [DAVIE] B. Davie, Yakov Rekhter, and Eric Rosen, "Use of Label Switching With RSVP", draft-davie-mpls-rsvp-00.txt, May 1997. [FANP] K. Nagami, Y.Katsube, Y. Shobatake, A. Mogi, S. Matsuzawa, T. Jinmei, and H. Esaki, "Toshiba's Flow Attribute Notification Protocol (FANP) Specification", RFC2129, April 1997. [IFMP] P. Newman, W. L. Edwards, R. Hinden, E. Hoffman, F. C. Liaw, T. Lyon, and G. Minshall, "Ipsilon Flow Management Protocol Specification for IPv4", RFC1953, May 1996. [TAG] Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow, and D. Farinacci, "Tag Switching Architecture - Overview", draft-rekhter-tagswitch-arch-00.txt, Jan. 1997. [TDP] P.Doolan, B.Davie, D.Katz, Y.Rekhter, and E.Rosen, "Tag Distribution Protocol", draft-doolan-tdp-spec-01.txt, May 1997. [VISWA] A. Viswanathan and V. Srinivasan, "Soft State Switching - A Proposal to Extend RSVP for Switching RSVP Flows -", draft-viswanathan-aris-rsvp-00.txt, March 1997. Katsube et al. Expires March 1998 [Page 11] Internet Draft Two Modes of Explicit LDP Sept. 1997 7. Authors Addresses Yasuhiro Katsube R&D Center, Toshiba Corporation, 1 Komukai-Toshiba-cho, Saiwai-ku, Kawasaki, 210, Japan Email: katsube@isl.rdc.toshiba.co.jp Yoshihiro Ohba R&D Center, Toshiba Corporation, 1 Komukai-Toshiba-cho, Saiwai-ku, Kawasaki, 210, Japan Email: ohba@csl.rdc.toshiba.co.jp Ken-ichi Nagami R&D Center, Toshiba Corporation, 1 Komukai-Toshiba-cho, Saiwai-ku, Kawasaki, 210, Japan Email: nagami@isl.rdc.toshiba.co.jp Katsube et al. Expires March 1998 [Page 12]