--- 1/draft-ietf-mpls-multicast-04.txt 2006-02-05 00:41:53.000000000 +0100 +++ 2/draft-ietf-mpls-multicast-05.txt 2006-02-05 00:41:53.000000000 +0100 @@ -1,25 +1,25 @@ Network Working Group D. Ooms, B. Sales Internet Draft Alcatel -Expiration Date: June 2001 W. Livens +Expiration Date: July 2001 W. Livens Colt Telecom A. Acharya IBM F. Griffoul Ulticom F. Ansari Bell Labs - December 2000 + January 2001 Framework for IP Multicast in MPLS - draft-ietf-mpls-multicast-04.txt + draft-ietf-mpls-multicast-05.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. @@ -51,22 +51,21 @@ 1. Introduction 2. Layer 2 characteristics 3. Taxonomy of IP multicast routing protocols in the context of MPLS 3.1. Aggregation 3.2. Flood & Prune 3.3. Source/Shared trees 3.4. Co-existence of Source and Shared Trees 3.5. Uni/Bi-directional Shared Trees 3.6. Encapsulated multicast data 3.7. Loop-free-ness - 3.8. RPF Check - 3.9. Mapping of characteristics on existing protocols + 3.8. Mapping of characteristics on existing protocols 4. Mixed L2/L3 forwarding in a single node 5. Taxonomy of IP multicast LSP triggers 5.1. Request driven 5.1.1. General 5.1.2. Multicast routing messages 5.1.3. Resource reservation messages 5.2. Topology driven 5.3. Traffic driven 5.3.1. General 5.3.2. An implementation example @@ -104,33 +103,31 @@ LSR Label Switching Router LSRd Downstream LSR LSRu Upstream LSR MOSPF Multicast OSPF mp2mp multipoint-to-multipoint p2mp point-to-multipoint PIM-DM Protocol Independent Multicast-Dense Mode PIM-SM Protocol Independent Multicast-Sparse Mode QoS Quality of Service RP Rendezvous Point - RPF Reverse Path Forwarding + RPT-bit RP Tree bit [DEER] RSVP Resource reSerVation Protocol + SPT-bit Shortest Path Tree [DEER] SSM Source Specific Multicast TCP Transmission Control Protocol UDP User Datagram Protocol VC Virtual Circuit VCI Virtual Circuit Identifier VP Virtual Path VPI Virtual Path Identifier - Changes - clean up references - changes to section of Explicit - Routing - added SSM to multicast protocol taxonomy - 1. Introduction In an MPLS cloud the routes are determined by a L3 routing protocol. These routes can then be mapped onto L2 paths to enhance network performance. Besides this, MPLS offers a vehicle for enhanced network services such as QoS/CoS, traffic engineering, etc. Current unicast routing protocols generate a same (optimal) shortest path in steady state for a certain (source, destination)-pair. Remark that unicast protocols can behave slightly different with regard to @@ -190,21 +187,20 @@ Following characteristics are considered: - Aggregation - Flood & Prune - Source/Shared trees - Co-existence of Source and Shared Trees - Uni/Bi-directional shared trees - Encapsulated multicast data - Loop-free-ness - - RPF check The discussion of these characteristics will not lead to the selection of one superior multicast routing protocol. It is not impossible that different IP multicast routing protocols will be deployed in the Internet. 3.1. Aggregation In unicast different destination addresses are aggregated to one entry in the routing table, yielding one FEC and one LSP. @@ -475,31 +472,22 @@ Multicast routing protocols which depend on a unicast routing protocol suffer from the same transient loops as the unicast protocols do, however the effect of loops will be much worse in the case of multicast. The reason being, each time a multicast packet goes around a loop, copies of the packet may be emitted from the loop if branches exist in the loop. Currently loop detection is a configurable option in LDP and a decision on the mechanism for loop prevention is postponed. -3.8. RPF Check - - Some protocols perform a Reverse Path Forwarding (RPF) check on the - received multicast packets. This mechanism checks whether the packet - is received on the interface which is on the shortest path to the - source (or root). This mechanism can introduce problems when - explicit routing is used (see section 7). Indeed, explicit routing - can construct a tree yielding another incoming interface than the - RPF-compatible one. +3.8. Mapping of characteristics on existing protocols -3.9. Mapping of characteristics on existing protocols The above characteristics are summarized in Table 1 for a non- exhaustive list of existing IP multicast routing protocols: DVMRP [PUSA], MOSPF [MOY], CBT [BALL], PIM-DM [DEER], PIM-SM [DEE2], SSM [HOLB], SM [PERL]. +------------------+------+------+------+------+------+------+------+ | |DVMRP |MOSPF |CBT |PIM-DM|PIM-SM|SSM |SM | +------------------+------+------+------+------+------+------+------+ |Aggregation |no |no |no |no |no |no |no | +------------------+------+------+------+------+------+------+------+ @@ -508,23 +496,20 @@ |Tree Type |source|source|shared|source|both |source|shared| +------------------+------+------+------+------+------+------+------+ |State Co-existence|no |no |no |no |yes |no |no | +------------------+------+------+------+------+------+------+------+ |Uni/Bi-directional|N/A |N/A |bi |N/A |uni |uni |bi | +------------------+------+------+------+------+------+------+------+ |Encapsulation |no |no |yes |no |yes |no |yes | +------------------+------+------+------+------+------+------+------+ |Loop Free |no |no |no |no |no |no |no | +------------------+------+------+------+------+------+------+------+ - |RPF check |yes |yes |no |yes |yes |yes |no | - +------------------+------+------+------+------+------+------+------+ - Table 1. Taxonomy of IP Multicast Routing Protocols From Table 1 one can derive e.g. that DVMRP will consume a lot of labels when the Flood & Prune L3 tree is mapped onto a L2 tree. Furthermore since DVMRP uses source trees it experiences no merging problem when label switching is applied. The table can be interpreted in the same way for the other protocols. 4. Mixed L2/L3 forwarding in a single node @@ -568,21 +553,21 @@ Table. Although the mixed L2/L3 forwarding requires processing of the traffic at L3, the load on the L3 forwarding engine is generally less than in a pure L3 node. Supporting this 'mixed L2/L3 forwarding' feature has following advantages: a) Assume LSR A (Figure 8) is an MPLS edge node for the branch - towards LSR B and an MPLS root node for the branch towards LSR C. + towards LSR B and an MPLS core node for the branch towards LSR C. The mixed L2/L3 forwarding allows that the branch towards C is not disturbed by a return to L3 in LSR A. +-------------+ | MPLS cloud | | N | | / \ | | / \ | | / \ | | A N | @@ -876,34 +863,34 @@ Piggybacking is just one possible component of an MPLS multicast solution. 7. Explicit routing Explicit routing for unicast refers to overriding the unicast routing table by using LSPs. A first way to interpret "multicast explicit routing" is overriding the tree established by the multicast routing protocol by another LSP - tree (e.g. a centrally calculated Steiner tree). In this + tree (e.g. a Steiner tree calculated by an offline tool). In this interpretation the current 'shortest path' multicast routing protocol becomes obsolete and can be replaced by label advertisement messages - that follow an explicit route which is e.g. calculated by an offline - tool. + that follow an explicit route (e.g. a branch of the Steiner tree). - A second way of interpreting "multicast explicit routing" is that - multicast routing protocols use the explicit unicast routes to - construct trees. This approach requires that the RPF check also - takes the explicit path into account. + A second way of interpreting "multicast explicit routing" is that the + known multicast routing protocols are running, but that the messages + generated by these protocols use explicit unicast routes (instead of + the IGP shortest path routes) to construct trees. 8. QoS/CoS 8.1. DiffServ + The Differentiated Services approach can be applied to multicast as well. It introduces finer stream granularities (DiffServ Codepoint (DSCP) as an extra differentiator). A sender can construct one or more trees with different DSCPs. These (S, G, DSCP) or (*, G, DSCP) trees can be mapped very easily onto LSPs when the traffic driven trigger is used. In this case one can create LSPs with different attributes for the various DSCPs. Note however that these LSPs still use the same route as long as the tree construction mechanism itself does not take the DSCP as an @@ -945,21 +932,21 @@ 1) Each LSR on the multi-access link memorizes all the advertised labels on the link, even if it has not received a join for the associated group. If an LSR is added to the multi-access link it has to retrieve this information from another LSR on the link or in case of soft state label advertisement it can wait a certain time before it can allocate labels itself. If LSRs allocate a label 'at the same moment' the LSR with the highest IP address could keep it, while the other LSRs withdraw the label. 2) Each LSR gets its own label range to allocate labels from. A - mechanism for label partitioning is described in [FAR2]. If an LSR + mechanism for label partitioning is described in [FARI]. If an LSR is added to the multi-access link the label ranges have to be negotiated again and possibly existing LSPs are teared down and are reconstructed with other labels. 3) Per multi-access link one LSR could be elected to be responsible for label allocation. When an LSR needs a label, it can request it from this Label Allocation LSR. Unlike the unicast case, a multicast stream can have more than one downstream LSR which all have to use the same label. Two solutions @@ -1154,103 +1142,96 @@ References [ACHA] A. Acharya, R. Dighe and F. Ansari, "IP Switching Over Fast ATM Cell Transport (IPSOFACTO) : Switching Multicast flows", IEEE Globecom '97. [AWDU] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow and V. Sriniva- san, "Extensions to RSVP for LSP Tunnels", Work In Progress [ANDE] L. Andersson, P. Doolan, N. Feldman, A. Fredette and R. Thomas, - "Label Distribution Protocol", Work In Progress. + "LDP specification", RFC3036, January 2001. [BALL] A. Ballardie, "Core Based Trees (CBT) Multicast Routing Archi- tecture", RFC2201, September 1997. -[CALL] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow and A. - Viswanathan, "A Framework for Multiprotocol Label Switching", - Work In Progress. - [CONT] A. Conta, P. Doolan, A. Malis, "Use of Label Switching on Frame - Relay Networks", Work In Progress. + Relay Networks", RFC3034, January 2001. [CRAW] E. Crawley, Editor, L. Berger, S. Berson, F. Baker, M. Borden and J. Krawczyk, "A Framework for Integrated Services and RSVP over ATM", RFC2382, August 1998. [DAVI] B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G. - Swallow and P. Doolan, "MPLS using ATM VC switching", Work In - Progress. + Swallow and P. Doolan, "MPLS using LDP and ATM VC switching", + RFC3035, January 2001. [DEER] S. Deering, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma and L Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2117, June 1997. [DEE2] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, Protocol Independent Multicast Version 2 Dense Mode Specification", Work In Progress. [FARI] D. Farinacci, Y. Rekhter and E. Rosen, "Using PIM to Distribute MPLS Labels for Multicast Routes", Work In Progress. -[FAR2] D. Farinacci and Y. Rekhter, "Partitioning Label Space among - Multicast Routers on a Common Subnet", Work In Progress. - [FENN] W. Fenner, "Internet Group Management Protocol, IGMP, version 2", RFC 2236, November 1997. [GARR] M. Garrett and M. Borden, "Interoperation of Controlled-Load Service and Guaranteed Service with ATM", RFC2381, August 1998. [HOLB] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work In Progress. [MOY] J. Moy, "Multicast extensions to OSPF", RFC 1584, March 1994. [NAGA] K. Nagami, N. Demizu, H. Esaki, Y. Katsube and P. Doolan, "VCID - Notification over ATM link for LDP", Work In Progress. + Notification over ATM link for LDP", RFC3038, January 2001. [PERL] R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. Maufer, "Simple Multicast", Work In Progress. [PUSA] T. Pusateri, "Distance Vector Multicast Routing Protocol", Work In Progress. [PAXS] V. Paxson, "End-to-End Routing Behavior in the Internet", IEEE/ACM Transactions on Networking 5(5), pp. 601-615. [ROSE] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G. Fedorkow, T. - Li, A. Conta, "MPLS Label Stack Encoding", Work In Progress. + Li, A. Conta, "MPLS Label Stack Encoding", RFC3032, January + 2001. Authors Addresses Dirk Ooms Alcatel Corporate Research Center - Fr. Wellesplein 1, 2018 Antwerpen, Belgium. + Fr. Wellesplein 1, 2018 Antwerp, Belgium. Phone : 32 3 2404732 Fax : 32 3 2409879 E-mail: Dirk.Ooms@alcatel.be Bernard Sales Alcatel Corporate Research Center - Fr. Wellesplein 1, 2018 Antwerpen, Belgium. + Fr. Wellesplein 1, 2018 Antwerp, Belgium. Phone : 32 3 2409574 E-mail: Bernard.Sales@alcatel.be Wim Livens Colt Telecom - Zweefvliegtuigstraat 10, 1130 Brussel, Belgium + Zweefvliegtuigstraat 10, 1130 Brussels, Belgium Phone : 32 2 7901705 Fax : 32 2 7901711 E-mail: WLivens@colt-telecom.be - Arup Acharya IBM TJ Watson Research Center 30 Saw Mill River Road, Hawthorne NY 10532 Phone : 1 914 784 7481 E-mail: arup@us.ibm.com Frederic Griffoul Ulticom, Inc. Les Algorithmes, 2000 Route des Lucioles, BP29 @@ -1255,11 +1236,11 @@ Ulticom, Inc. Les Algorithmes, 2000 Route des Lucioles, BP29 06901 Sophia-Antipolis, FRANCE E-mail: griffoul@ulticom.com Furquan Ansari Bell Labs 101 Crawfords Corner Rd., Holmdel, NJ 07733 Phone : 1 732 949 5149 Fax : 1 732 332 6511 - E-mail: furquan@dnrc.bell-labs.comy + E-mail: furquan@dnrc.bell-labs.com