From owner-pim@catarina.usc.edu Thu May 6 03:07:56 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA19613 for ; Thu, 6 May 1999 03:07:56 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id XAA10689 for pim-list; Wed, 5 May 1999 23:56:58 -0700 Received: from fsnt.future.futsoft.com ([38.242.192.5]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id XAA10681 for ; Wed, 5 May 1999 23:56:16 -0700 Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Thu, 06 May 1999 12:27:33 +0530 Received: from msgate.future.futsoft.com (msgate.future.futsoft.com [10.0.8.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id MAA27999 for ; Thu, 6 May 1999 12:25:06 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <3731ECAA@msgate.future.futsoft.com>; Thu, 06 May 99 12:25:30 PDT From: rajas To: "'pim@catarina.usc.edu'" Subject: RFCs 2117 and 2362 Date: Thu, 06 May 99 12:23:00 PDT Message-Id: <3731ECAA@msgate.future.futsoft.com> X-Mailer: Microsoft Mail V3.0 Sender: owner-pim@catarina.usc.edu Precedence: bulk Hello , Can anybody list the differences between the RFCs 2362 and 2117 for PIM-SM. Or a pointer where I can find a comprehensive list would also be very helpful. Expecting response as early as possible. Thanks in advance. Regards S.Rajagopalan From owner-pim@catarina.usc.edu Fri May 7 00:10:06 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09752 for ; Fri, 7 May 1999 00:10:04 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id UAA15686 for pim-list; Thu, 6 May 1999 20:55:00 -0700 Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id UAA15682 for ; Thu, 6 May 1999 20:54:55 -0700 Received: (dino@localhost) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id UAA23952; Thu, 6 May 1999 20:54:22 -0700 (PDT) Date: Thu, 6 May 1999 20:54:22 -0700 (PDT) Message-Id: <199905070354.UAA23952@flipper.cisco.com> From: Dino Farinacci To: pim@catarina.usc.edu Subject: Bidir-PIM draft Sender: owner-pim@catarina.usc.edu Precedence: bulk I will submit this as an Internet Draft once we get an IP Option number assigned. Dino ------------------------------------------------------------------------ Network Working Group Deborah Estrin Internet Draft USC/ISI Expiration Date: November 1999 Dino Farinacci cisco Systems May 5, 1999 Bi-Directional Shared Trees in PIM-SM 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 proposal extends the PIM-SM [1] mechanism for multicast datagram forwarding. PIM-SM constructs and maintains uni-directional shared trees and uni-directional source trees. We describe how we can extend the elements of operation of sparse-mode PIM to support bi- directional shared trees. 1. Introduction A uni-directional shared tree allows sources to send multicast datagrams to members of a multicast group. Members receive packets sent to the group by joining the shared tree, using a particular node in the network as the root of the shared tree. The root of the shared tree is called the Rendezvous Point (RP). When using undirectional shared trees, all sources' datagrams initially go to the root (RP) of the tree before being delivered down the distribution tree. As a Estrin, Farinacci [Page 1] Internet Draft PIM Bi-Directional Shared Trees May 1999 result, there can be suboptimal delivery paths to the receivers close to the source. In PIM-SM, the RP typically joins back to the source to draw datagrams down directly and natively (no encapsulation) from the source to the RP. The RP then forwards the datagrams down the uni- directional shared tree to the receivers. Eventually, receivers may join to the source as well, thus drawing datagrams down a source specific, uni-directional, shortest path tree. Or the receivers may continue to receive datagrams on the shared tree. When using bi-directional shared trees, data can flow in either direction on a branch of the tree. This allows improved data delivery to receivers close to the source because the traffic traveling upstream to the root node is "turned around" and forwarded on downstream branches [2]. The bi-directional shared trees described in this extension to PIM-SM are used both to distribute datagrams from sources to the RP, as well as to distribute datagrams directly to receivers. Moreover, the protocol does not build source-specific trees from sources to the RP, nor to receivers. Instead, source transmissions travel up the shared tree toward the RP providing coverage to receivers along the way. The RP only needs to forward datagrams downward on those branches of the shared tree not covered by the path from the source to the RP. However, bi-directional trees are incompatible with source specific uni-directional trees and so no switching to source-trees is allowed. Source-trees have the best delay characteristics so there is a tradeoff between uni-directional shared trees with source-trees and bi-directional shared trees. For large numbers of moderate to low rate sources, bi-directional PIM may offer significant advantages. 2. Pros and Cons of Bi-Directional Shared Trees There are 3 basic advantages of bi-directional shared trees: 1. State is reduced compared to source trees. Each router in the multicast routing domain needs only keep state for the group and not each source sending to each group. [2] 2. Datagrams from sources to topologically near-by receivers do not have to travel all the way to the root of the shared tree. These improved distribution paths also support better scoping semantics for applications that might use TTL based expanding ring scope to look for nearby resources. Estrin, Farinacci [Page 2] Internet Draft PIM Bi-Directional Shared Trees May 1999 3. Bursty sources can send with no or little state in routers. There are 3 basic disadvantages of bi-directional shared trees: 1. Since all traffic eventually goes to the root of the tree, there is a traffic concentration point at the root node and links leading to it (pruning mechanisms could be added but at the cost of additional state and complexity). Traffic always flows to the root node even when it doesn't have to. That is, if the root node has a single sender branch, the root does not take part in forwarding traffic but it must receive the traffic because downstream nodes don't know the group membership tree near the root. 2. The path taken between the source and receivers might not travel over the shortest path, although it is likely to be a shorter path than via a uni-directional shared tree. 3. Bi-directional trees are incompatible with uni-directional source-trees. There is an increase in complexity when both are used for the same group. Compared to CBT, the bi-directional trees proposed in this specification differ in two respects: 1. Non-member senders do not encapsulate their data to the root, the data is forwarded along the same path that it would take if the sender were also a member. 2. The protocol reuses much of the existing PIM-SM implementation. 3. Modifications to PIM A strong goal of this proposal is to make as few changes as possible to PIM and multicast forwarding. We also wish to make the changes compatible, to enable a phased (incrementally deployed) transition to bi-directional shared tree PIM. Therefore, we use (*,G) state to describe bi-directional shared tree state (traditionally (*,G) has been used to describe uni-directional shared tree state). By definition a PIM bi-directional shared tree group may not have any (S,G) state stored for the group. There are exceptions when mixing non-bidir PIM routers with bidir PIM routers (see later in this specification). We assume that at the same time a router learns the RP for a group, it will know if the group is to operate in bi-directional shared tree mode or uni-directional shared tree mode. This assumption greatly simplifies the deployment and operation of the protocol. Estrin, Farinacci [Page 3] Internet Draft PIM Bi-Directional Shared Trees May 1999 4. Modifications to Multicast Forwarding There will be modifications to multicast forwarding since bi- directional shared tree delivery requires traffic to flow upstream (towards the root). This is contrary to RPF forwarding rules used on uni-directional shared trees (datagrams can only be forwarded away from the root node, downstream towards receivers). 5. No Modifications to Multicast Capable Hosts This proposal does not require modifications to multicast capable hosts [3]. Hosts that receive multicast datagrams with the UMP option must ignore the option and accept the datagram [6]. 6. How are hosts Joined to a Bi-directional Shared Tree No change is required in hosts. Receiving hosts use IGMP [3] (as they do today) to join multicast groups. The attached designated router (DR) will initiate joining of the shared tree. The attached routers perform the same actions as are done to graft branches on the uni-directional tree. That is, the designated router (DR), on the attached subnet with the receiver, will send a PIM Join/Prune message for (*,G) with the RP in the Join-List toward the RP for the group. Routers maintain (*,G) state as defined in the sparse-mode PIM specification. [1] 7. How are Source's Datagrams sent onto a Bi-directional Shared Tree No change is required to hosts. A source host will send a multicast datagram by transmitting on it's attached interface (as it does today) [3]. The attached DR will initiate the delivery of the multicast datagram upstream towards the RP. When a datagram flows upstream, a receiving router must know that it can bypass the RPF check on the (*,G) entry. To accomplish this, we introduce a new IP option called the Upstream Multicast Packet (UMP). The UMP IP header option is encoded as follows: Estrin, Farinacci [Page 4] Internet Draft PIM Bi-Directional Shared Trees May 1999 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Router's IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type value is TBD. When a router forwards a multicast datagram upstream, it identifies the upstream router in the option. Only the indicated upstream router is responsible for forwarding the datagram upstream. When a router forwards a multicast datagram with the UMP option, it will multicast the datagram on the attached upstream subnet so other routers can forward datagrams down the shared tree if they have (*,G) state. Any directly attached members also receive the datagram. In most cases, only a single copy of the datagram is sent upstream, taking advantage of multi-access/multicast capable media whereever possible. However, on the first hop LAN, there may be two datagrams that traverse the LAN. See next section for details. It is important to note that symmetry between receivers and senders along the same branch must be maintained. That is, a router must join along the same path it would forward traffic upstream or loops could result. This specification forces symmetry because the same choice for forwarding and joining is achieved by using the RPF neighbor to the RP. 8. First-hop LAN When a source transmits a multicast datagram, there is one router on the attached LAN that will insert the UMP option. The PIM designated router (DR) will be responsible for this. The DR will insert the UMP option using the address of the next-hop router it knows to reach the RP for the (*,G) entry. There is one case where two datagrams traverse the first-hop LAN. The first datagram is transmitted as multicast by the source and the second is transmitted by the DR as MAC-level unicast to the next-hop upstream router. This only occurs when the DR uses the first-hop LAN as it's RPF interface for (*,G). If the DR is an upstream router, the extra datagram is not sent because the RPF interface for (*,G) is not the first-hop LAN. The DR is made responsible for selecting the upstream router in order Estrin, Farinacci [Page 5] Internet Draft PIM Bi-Directional Shared Trees May 1999 to avoid inconsistent join and forwarding decisions if multiple downstream routers on the LAN receive joins or datagrams for the same group. If all routers on a LAN always ran a common link state protocol or always had some other means to guarantee consistent routing information, then this would not be necessary. However, in order to allow loop free operation in the widest range of environments, without making restrictive assumptions about unicast routing protocols, configurations and policies, we make use of the DR to enforce consistent decisions. A network administrator can control which router is the PIM DR [5] to avoid particular suboptimal cases. 9. Multicast Forwarding Rules The following steps describe the rules for bi-directional shared tree forwarding in PIM. When a router receives a multicast datagram, it may arrive on the RPF interface for a (*,G) entry or another (the non-RPF) interface. A. When a multicast datagram arrives on the RPF interface toward the RP: A1. A multicast routing table lookup is performed. Only a (*,G) entry can be returned (based on our definition that PIM bi-directional shared trees groups will not have (S,G) route entries). If the entry is not found, the datagram is silently discarded. A2. If the entry is found, the datagram is sent out each outgoing interface that resides in the outgoing interface list for the (*,G) entry. In this situation, the router doesn't care if the (*,G) tree state is bi-directional or uni-directional. A3. Before replicating the datagram on each outgoing interface, a router checks to see if the UMP option is present. If so, it can either remove the option or replace the existing address with 0.0.0.0 in the Upstream Router IP Address field. This is to indicate to downstream routers the datagram is not traveling upstream. A4. If the UMP option isn't present and the router is DR on the interface the datagram was received on and the source is directly attached, the DR is responsible for inserting the UMP option. It includes in the UMP option address the next-hop IP address of it's RPF neighbor for (*,G). The DR forwards the datagram using the MAC-level address (unicast address) of this RPF neighbor. A5. If the UMP option isn't present and the router isn't the DR, or the Estrin, Farinacci [Page 6] Internet Draft PIM Bi-Directional Shared Trees May 1999 source isn't directly attached, the datagram is silently discarded. B. When multicast datagram arrives on a non-RPF interface toward the RP: B1. A multicast routing table lookup is performed. Only a (*,G) entry can be returned (based on our definition of PIM bi-directional shared trees). B2. The router looks at the UMP option. If the option is present and the Upstream Router IP Address is not it's own IP address on the received interface, the datagram is silently discarded. B3. If the UMP option is not present and the router is directly connected to the source of the multicast datagram and is the DR on the interface, the DR inserts the UMP option and follows the steps B4.1 and B4.2. B4. If the UMP option is present and the Upstream Router IP Address field contains the IP address of the receiving router (on the received interface), it will forward the datagram as follows: B4.1 The datagram is sent out each outgoing interface that resides in the outgoing interface list for the (*,G) entry except for the interface on which the datagram was received on. Before sending out each interface, the router may remove the UMP option from the datagram or replace the existing address with 0.0.0.0 in the Upstream Router IP Address field. B4.2 The datagram is forwarded on the RPF interface for (*,G) by replacing the Upstream Router IP Address field in the UMP option with the next-hop address of the router that is used to reach the RP. 10. Distinguishing Bi-Directional Shared Tree Groups from other Groups When routers discover the identity of the RP for a multicast group they can determine if the group will operate in bi-directional shared tree mode or uni-directional tree mode. We modify the Encoded-Group Address fields in PIM Bootstrap and Candidate-RP Advertisement messages to include the Bidir-bit (see bit B below): Estrin, Farinacci [Page 7] Internet Draft PIM Bi-Directional Shared Trees May 1999 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type |B| Reserved | Mask Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Multicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the Bidir-bit is set, all upgraded bi-directional PIM routers will follow the forwarding rules described in this specification. 11. Mixing Bi-Directional Capable with Uni-Directional-Only Routers It will take time to upgrade all PIM routers in a domain to be bi- directional shared tree capable. However, enabling bi-directional shared tree routers in an existing network can be easy and simple. First, no special attention at the protocol level needs to be taken if the network is engineered where you can place bidir PIM routers strategically near sources. That is, if sources are located on sender-only branches (no Joins have traveled up that branch) of the bi-directional shared tree, only that branch needs to be upgraded with bi-directional shared tree capable routers. All other routers on receiver branches forward based on (*,G) uni-directional shared tree forwarding rules. When the network cannot be engineered to locate bi-directional shared tree capable routers on sender-only branches, the following transition support can be implemented: o A router will detect if it's upstream neighboring router toward the RP is bi-directional shared tree capable or not. We will use the Bidir-Capable PIM Hello Option to convey this information. o A router that is one-hop downstream (of the RP) from a non-bidir capable router will maintain (S,G) state and will be responsible for forwarding multicast traffic as to the RP by Registering to the RP as it would if it was a DR (or MBR) in uni-directional mode. When the data arrives at the RP, it can be delivered on the uni-directional shared-tree (or any source trees that overlap with the shared tree). Estrin, Farinacci [Page 8] Internet Draft PIM Bi-Directional Shared Trees May 1999 We define the following PIM Hello Option: Bidir-Capable Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType | OptionLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionValue | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType | OptionLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionValue | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OptionType = 19 (decimal) OptionLength The length of the option payload in bytes. This is set to 0. Therefore, the following encoding is inserted in the PIM Hello mes- sage: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 19 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ By definition, in a pure bi-directional router environment, a bidir capable PIM router will not create (S,G) state when it either 1) receives a datagram or 2) receives any PIM control message. However, there is one exception. When a router receives a datagram that is traveling upstream (the UMP option is present or the router is the DR directly attached to the source) and the upstream neighbor toward the RP is not bidir capable, it will create (S,G) state and set the necessary flags indicating datagrams that match the route entry will be Register encapsulated to the RP. In this case, the router still doesn't accept join messages (and therefore doesn't populate the (S,G) olist) if there are routers upstream that are sending (S,G) Joins or Prunes. A router that does this transition logic is called, Estrin, Farinacci [Page 9] Internet Draft PIM Bi-Directional Shared Trees May 1999 a bidir border router. If a bidir router creates (S,G) state for a bi-directional group, it will not send Join/Prune messages for the entry. If a bidir router changes it's RPF neighbor toward the RP and the RPF neighbor is bidir capable, it will delete it's (S,G) entries. A bidir router must do longest match lookups for a group that is in bi-directional tree mode. This handles the case where the RP forwards datagrams down a branch that has a both a sender and a member on it and avoids datagrams returning to the sender. In this case, a bidir border router should RPF fail for such datagrams since it will use the (S,G) entry rather than the (*,G) entry for the forwarding decision. If the RP is a bidir capable router and it receives a Register message, it will not create (S,G) state. It will forward the data encapsulated in the Register message down the shared tree. The RP will only send a Register-Stop if there are no members for the group (the (*,G) outgoing interface list is empty). An RP will receive a Register message in two cases, 1) the DR is a non-bidir capable router, or 2) it was sent by a bidir border router. If the RP is not bidir capable and it receives a Register from either a non-bidir capable DR or a bidir border router, it may trigger a Join toward the source. If there are any bidir capable routers on the path, they will not create (S,G) state. In this case, the RP will never get data natively and therefore never send Register-Stop messages. The data will continue to be delivered via Register encapsulation. Estrin, Farinacci [Page 10] Internet Draft PIM Bi-Directional Shared Trees May 1999 The following shows all possible cases mixing non-bidir (old) and bidir capable (new) routers. Each column shows the capability of 1) the RP, 2) an router between the DR and the RP, and 3) the DR. The following notation is used: "new-rp" - RP is bidir capable "old-rp" - RP is non-bidir capable "old" - router is non-bidir capable "new" - router is bidir capaple "new-dr" - DR is bidir capable "old-dr" - DR is non-bidir capable (1) (2) (3) (4) (5) (6) (7) (8) old-rp old-rp old-rp old-rp new-rp new-rp new-rp new-rp old old new new new new old old old-dr new-dr old-dr new-dr new-dr old-dr new-dr old-dr (1) This case is uni-directional mode. (2) The bidir DR sends Registers and does not forward datagrams with the UMP option. It does this because it detects the upstream router is not bidir-capable. The RP joins back to the source through the intermediate router. The intermediate router's join is ignored by the bidir DR. Datagrams get to receivers via Register encapsulation only from the DR. (3) The non-bidir DR sends Registers. The non-bidir RP may send joins but the bidir intermediate router will ignore them. Datagrams get to receivers via Register encapsulation only from the DR. (4) The bidir DR forwards multicast datagram with the UMP option upstream. It does this because it detects the upstream router is bidir-capable. The bidir intermediate router (acting as a bidir border router) sends Registers to the non-bidir RP. Datagrams get to receivers via Register encapsulation only from the bidir border router. (5) This case is bi-directional shared tree mode. (6) The non-bidir DR will Register to the bidir RP. The bidir RP will not send Joins back to the source. It only Register-Stops if there are no members. The bidir intermediate router is not involved in forwarding multicast datagrams. Datagrams get to receivers via Register encapsulation only from the DR. (7) The bidir DR will Register to the bidir RP. It does this because it detects the upstream router is non-bidir capable. It is performing as a bidir border router. The bidir RP will not send Joins back to Estrin, Farinacci [Page 11] Internet Draft PIM Bi-Directional Shared Trees May 1999 the source. It only Register-Stops if there are no members. The non-bidir intermediate router is not involved in forwarding multicast datagrams. Datagrams get to receivers via Register encapsulation only from the DR. (8) The non-bidir DR will Register to the bidir RP. The bidir RP will not send Joins back to the source. It only Register-Stops if there are no members. The non-bidir intermediate router is not involved in forwarding multicast datagrams. Datagrams get to receivers via Register encapsulation only from the DR. 12. Security Considerations When IPsec [4] is used on a multicast datagram, the UMP IP option will not be part of the encrypted payload. This is justified by allowing routers to be performant when forwarding datagrams upstream. Estrin, Farinacci [Page 12] Internet Draft PIM Bi-Directional Shared Trees May 1999 13. Acknowledgments The authors would like to acknowledge Rusty Eddy (USC), Radia Perlman (Sun), Tony Speakman (cisco), and Liming Wei (cisco) for their comments and contributions to this specification. 14. Author Information Deborah Estrin ISI/USC estrin@usc.edu Dino Farinacci cisco Systems, Inc. dino@cisco.com 15. References [1] Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM- SM): Protocol Specification", RFC 2362, June 1998. [2] A.J. Ballardie, P.F. Francis, and J.Crowcroft. Core based trees. In Proceedings of the ACM SIGCOMM, San Francisco, 1993. [3] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989. [4] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995. [5] Wei, L., Farinacci, D., "PIM Version 2 DR Election Priority Option", INTERNET-DRAFT, March 1998. [6] ISI/USC, "Internet Protocol", RFC 791, September 1981. Estrin, Farinacci [Page 13] From owner-pim@catarina.usc.edu Sat May 8 14:51:12 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04168 for ; Sat, 8 May 1999 14:51:11 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA20696 for pim-list; Sat, 8 May 1999 11:45:11 -0700 Received: from excalibur.usc.edu (excalibur.usc.edu [128.125.51.11]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA20692; Sat, 8 May 1999 11:45:05 -0700 Received: (ahelmy@localhost) by excalibur.usc.edu (8.6.10/8.6.9) id LAA23806; Sat, 8 May 1999 11:45:03 -0700 Date: Sat, 8 May 1999 11:45:01 -0700 (PDT) From: Ahmed A-G Helmy To: rajas cc: "'pim@catarina.usc.edu'" Subject: Re: RFCs 2117 and 2362 In-Reply-To: <3731ECAA@msgate.future.futsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk > Hello , > > Can anybody list the differences between the RFCs 2362 and 2117 for > PIM-SM. Or a pointer where I can find a comprehensive list would also be > very helpful. there should be a section at the end of the spec indicating the changes from the last version/previous versions, check the pim web page catarina.usc.edu/pim Regs, -A > > Expecting response as early as possible. > > Thanks in advance. > > Regards > S.Rajagopalan > From owner-pim@catarina.usc.edu Tue May 11 12:09:40 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01468 for ; Tue, 11 May 1999 12:09:40 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA29307 for pim-list; Tue, 11 May 1999 08:52:55 -0700 Received: from fsnt.future.futsoft.com ([38.242.192.5]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id IAA29303 for ; Tue, 11 May 1999 08:52:44 -0700 Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Tue, 11 May 1999 21:23:44 +0530 Received: from altoona.future.futsoft.com (altoona.future.futsoft.com [10.0.6.19]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id VAA03882 for ; Tue, 11 May 1999 21:20:21 +0530 Received: by altoona.future.futsoft.com with Microsoft Mail id <01BE9BF3.FB64D480@altoona.future.futsoft.com>; Tue, 11 May 1999 21:19:41 +0530 Message-Id: <01BE9BF3.FB64D480@altoona.future.futsoft.com> From: Samvid Cc: "'pim@catarina.usc.edu'" Subject: backward compatibiltiy of PIMv2 Date: Tue, 11 May 1999 21:19:37 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit hi, please let me know to what extent PIMv2 is backward compatible with PIMv1 ? Thanks in advance. -Samvid From owner-pim@catarina.usc.edu Tue May 11 12:27:02 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01714 for ; Tue, 11 May 1999 12:27:02 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id JAA29414 for pim-list; Tue, 11 May 1999 09:12:11 -0700 Received: from corona.jcmax.com (corona.jcmax.com [204.69.248.2]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id JAA29410 for ; Tue, 11 May 1999 09:12:04 -0700 Received: from extreme.jcmax.com by corona.jcmax.com (5.65/2.73G/4.1.3_U1) id AA22223; Tue, 11 May 99 12:11:57 -0400 Received: from extreme.jcmax.com (localhost.jcmax.com [127.0.0.1]) by extreme.jcmax.com (8.8.7/8.7.3) with ESMTP id MAA17076; Tue, 11 May 1999 12:11:57 -0400 (EDT) Message-Id: <199905111611.MAA17076@extreme.jcmax.com> To: Samvid Cc: "'pim@catarina.usc.edu'" Subject: Re: backward compatibiltiy of PIMv2 In-Reply-To: Your message of "Tue, 11 May 1999 21:19:37 +0530." <01BE9BF3.FB64D480@altoona.future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <17073.926439116.1@extreme.jcmax.com> Date: Tue, 11 May 1999 12:11:56 -0400 From: Tom Pusateri Sender: owner-pim@catarina.usc.edu Precedence: bulk In message <01BE9BF3.FB64D480@altoona.future.futsoft.com> you write: >hi, > please let me know to what extent PIMv2 is backward compatible with PI >Mv1 ? > > > Thanks in advance. > -Samvid The protocol messages themselves are not compatible. However, routers that implement both versions can do translation in a compatible way that is transparent to the multicast data being delivered. Tom From owner-pim@catarina.usc.edu Tue May 11 20:32:43 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05568 for ; Tue, 11 May 1999 20:32:42 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA01600 for pim-list; Tue, 11 May 1999 17:23:03 -0700 Received: from ns.bigbear.net (lai-ca4-68.ix.netcom.com [209.110.247.68]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id RAA01546; Tue, 11 May 1999 17:22:11 -0700 From: toukol@mindspring.com Message-Id: <199905120022.RAA01546@catarina.usc.edu> Subject: Homeworkers Needed! Date: Tue, 11 May 1999 13:48:49 Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Sender: owner-pim@catarina.usc.edu Precedence: bulk Dear Future Associate, You Can Work At Home & Set Your Own Hours. Start earning Big Money in a short time NO Newspaper Advertising! Your job will be to stuff and mail envelopes for our company. You will receive $.25 for each and every envelope you stuff and mail out. Just follow our simple instructions and you will be making money as easy as 1… 2… 3 For example stuff and mail 200 envelopes and you will receive $50.00. Stuff and mail 1000 and you will receive $250.00. Stuff and mail 2000 and you will receive $500.00 and more Never before has there been an easier way to make money from home! Our Company's Home Mailing Program is designed for people with little or no experience and provides simple, step by step instructions. There is no prior experience or special skills necessary on your part, Just stuffing envelopes. We need the help of honest and reliable home workers like you. Because we are overloaded with work and have more than our staff can handle. We have now expanded our mailing program and are expecting to reach millions more with our offers throughout the US and Canada. Our system of stuffing and mailing envelopes is very simple and easy to do! You will not be required to buy envelopes or postage stamps. We will gladly furnish all circulars at no cost to you. We assure you that as a participant in our program you will never have to mail anything objective or offensive. There are no quotas to meet, and there no contracts to sign. You can work as much, or as little as you want. Payment for each envelope you send out is Guaranteed! Here is what you will receive when you get your first Package. Inside you will find 100 envelopes, 100 labels and 100 sales letters ready to stuff and mail As soon as you are done with stuffing and mailing these first letters, your payment will arrive shortly, thereafter. All you have to do is to order more free supplies and stuff and mail more envelopes to make more money. Our sales literature which you will be stuffing and mailing will contain information outlining our highly informative manuals that we are advertising nationwide. As a free gift you will receive a special manual valued at $24.95, absolutely free, just for joining our Home Mailers Program. Plus you will get your own special code number, so that we will know how much you are to get paid. And to make re-ordering of more envelopes, that our company supplies very simple for you. We are giving you this free bonus because we want you to be confident in our company and to ensure that we will be doing business with you for a long time. Benefits Of This Job: 1. You do not have to quit your present job, to earn more money at home 2. You can make between $2,500 to $4,500 a month depending on the amount of time you are willing to spend stuffing and mailing envelopes 3. This is a great opportunity for the students, mothers, disabled persons or those who are home bodies. To secure your position and to show us that you are serious about earning extra income at home we require a one-time registration fee of $35.00. This fee covers the cost of your initial start up package, which includes 100 envelopes, 100 labels and 100 sales letters and a manual, your registration fee will be refunded back to you shortly thereafter. Money Back Guarantee! We guarantee that as soon as you stuff and mail your first 300 envelopes You will be paid $75.00 and your registration fee will be refunded. Many of you wonder why it is necessary to pay a deposit to get a job. It is because we are looking for people that seriously want to work from home. * If 3.000 people told us they wanted to start working from home and we sent out 3.000 packages free to every one. And then half of the people decided not to work, this would be a potential loss of more than $60,000 in supply's and shipping that we have sent out to people that don't want to work We have instituted this policy to make sure that you really want to work and at least finish your first package. To Get Started Today Please Enclose Your Registration Fee of $35 Check,Cash Or Money Order and fill out the application below and mail to: AHWA CO Pmb 1928 E. Highland Blvd Ste #F104-902 Phoenix, Az 85016 Name_____________________________________________________ Address___________________________________________________ City____________________________________ State______________ Zip Code________________ Telephone Number(s)_________________________________________ E-mail Address______________________________________________ For all orders, please allow seven (7) days for delivery and up to 10 days. Cash and Money Orders will result in faster shipping of your package. From owner-pim@catarina.usc.edu Fri May 14 20:38:21 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08872 for ; Fri, 14 May 1999 20:38:20 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA15684 for pim-list; Fri, 14 May 1999 17:31:39 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id RAA15680 for ; Fri, 14 May 1999 17:31:33 -0700 Received: from mustang.iprg.nokia.com (mustang.iprg.nokia.com [205.226.1.196]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id RAA28671 for ; Fri, 14 May 1999 17:31:02 -0700 (PDT) Message-Id: <199905150031.RAA28671@mailhost.iprg.nokia.com> X-Mailer: exmh version 2.0.2 2/24/98 To: pim@catarina.usc.edu Subject: sorry about that last message, I've got too many pim mail aliases :-( Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 May 1999 17:31:01 -0700 From: "Danny J. Mitzel" Sender: owner-pim@catarina.usc.edu Precedence: bulk danny From owner-pim@catarina.usc.edu Fri May 14 20:41:24 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08894 for ; Fri, 14 May 1999 20:41:24 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA15657 for pim-list; Fri, 14 May 1999 17:28:58 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id RAA15652 for ; Fri, 14 May 1999 17:28:53 -0700 Received: from mustang.iprg.nokia.com (mustang.iprg.nokia.com [205.226.1.196]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id RAA28367 for ; Fri, 14 May 1999 17:28:22 -0700 (PDT) Message-Id: <199905150028.RAA28367@mailhost.iprg.nokia.com> X-Mailer: exmh version 2.0.2 2/24/98 To: pim@catarina.usc.edu Subject: update to PIM project plan doc Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 May 1999 17:28:22 -0700 From: "Danny J. Mitzel" Sender: owner-pim@catarina.usc.edu Precedence: bulk I checked in updates to the project plan doc. you can checkout and build the doc from your repository or see: /home/mitzel/nokproc/src/doc/ipsrd/pim/project_plan/pim_project_plan.ps /home/mitzel/nokproc/src/doc/ipsrd/pim/project_plan/html/pim_project_plan.html things to look at closely: - Task section: does the list look complete and efforts accurate - Timeline section: I think I still need to add a unit test on the Danny/Multiple Route Table line. also I think it might be better to move that unit test up before the config/monitor changes. then in our Milestones we'll have show the unit tests completed slightly earlier and some small time delta till release to QA. - Milestone section: need to complete ``Scheduled Date'' column when timeline stabilized. - Scalability section: comments on placement within doc and/or additional content? danny From owner-pim@catarina.usc.edu Thu May 20 09:19:46 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22208 for ; Thu, 20 May 1999 09:19:45 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id GAA04785 for pim-list; Thu, 20 May 1999 06:04:27 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id GAA04781 for ; Thu, 20 May 1999 06:04:22 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21487; Thu, 20 May 1999 09:03:47 -0400 (EDT) Message-Id: <199905201303.JAA21487@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pim@catarina.usc.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pim-v2-dm-02.txt Date: Thu, 20 May 1999 09:03:46 -0400 Sender: owner-pim@catarina.usc.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : Protocol Independent Multicast Version 2 Dense Mode Specification Author(s) : S. Deering, D. Estrin, D. Farinacci, V. Jacobson, A. Helmy, D. Meyer, L.Wei Filename : draft-ietf-pim-v2-dm-02.txt Pages : 17 Date : 19-May-99 This specification defines a multicast routing algorithm efficient for multicast groups that are densely distributed across a network. This protocol does not have a topology discovery mechanism often used by a unicast routing protocol. It employes the same packet formats sparse- mode PIM [PIMSM] uses. This protocol is called dense-mode PIM. The foundation of this design was largely built on Deering's early work on IP multicast routing [Deering91]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-v2-dm-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pim-v2-dm-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pim-v2-dm-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990519104756.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-v2-dm-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-v2-dm-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990519104756.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pim@catarina.usc.edu Thu May 20 10:37:25 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25620 for ; Thu, 20 May 1999 10:37:24 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id HAA04978 for pim-list; Thu, 20 May 1999 07:28:06 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id HAA04974 for ; Thu, 20 May 1999 07:28:00 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25201; Thu, 20 May 1999 10:27:23 -0400 (EDT) Message-Id: <199905201427.KAA25201@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pim@catarina.usc.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pim-v2-auth-01.txt Date: Thu, 20 May 1999 10:27:22 -0400 Sender: owner-pim@catarina.usc.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : Authenticating PIM version 2 messages Author(s) : L. Wei Filename : draft-ietf-pim-v2-auth-01.txt Pages : 4 Date : 19-May-99 This draft specifies the use of IPSEC authentication header [KA98] to provide protocol message integrity protection and groupwise message origin authentication. The text in this draft will be either incorporated into or referenced by the PIM version 2 protocol specifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-v2-auth-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pim-v2-auth-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pim-v2-auth-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990519130629.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-v2-auth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-v2-auth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990519130629.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pim@catarina.usc.edu Thu May 20 13:20:20 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00771 for ; Thu, 20 May 1999 13:20:15 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA05598 for pim-list; Thu, 20 May 1999 10:11:52 -0700 Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA05594 for ; Thu, 20 May 1999 10:11:48 -0700 Received: (lwei@localhost) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id KAA14673; Thu, 20 May 1999 10:11:10 -0700 (PDT) Date: Thu, 20 May 1999 10:11:10 -0700 (PDT) Message-Id: <199905201711.KAA14673@flipper.cisco.com> From: Liming Wei To: pim@catarina.usc.edu Subject: [Internet-Drafts@ietf.org: I-D ACTION:draft-ietf-pim-v2-dm-02.txt] Sender: owner-pim@catarina.usc.edu Precedence: bulk This version is the same as the one posted before the Minneapolis meeting, except the boilerplate was updated per the new ID requirements. So is the other submission on PIM authentication. BTW, the WG last call to move forward to PS on both drafts have expired. Also, I'd like to solicit comments on the current PIM-SM draft. I have collected past comments on the draft, both from messages on this list and those sent to us/me in private. I plan to work on them in the next week or so. I think most of them are of a clarification nature, and can be done pretty quickly. -Liming ------- Start of forwarded message ------- To: IETF-Announce:; Cc: pim@catarina.usc.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pim-v2-dm-02.txt Date: Thu, 20 May 1999 09:03:46 -0400 Sender: nsyracus@ns.cnri.reston.va.us - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : Protocol Independent Multicast Version 2 Dense Mode Specification Author(s) : S. Deering, D. Estrin, D. Farinacci, V. Jacobson, A. Helmy, D. Meyer, L.Wei Filename : draft-ietf-pim-v2-dm-02.txt Pages : 17 Date : 19-May-99 This specification defines a multicast routing algorithm efficient for multicast groups that are densely distributed across a network. This protocol does not have a topology discovery mechanism often used by a unicast routing protocol. It employes the same packet formats sparse- mode PIM [PIMSM] uses. This protocol is called dense-mode PIM. The foundation of this design was largely built on Deering's early work on IP multicast routing [Deering91]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-v2-dm-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pim-v2-dm-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pim-v2-dm-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990519104756.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-v2-dm-02.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-v2-dm-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990519104756.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of forwarded message ------- From owner-pim@catarina.usc.edu Thu May 20 16:14:18 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03737 for ; Thu, 20 May 1999 16:14:17 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA06446 for pim-list; Thu, 20 May 1999 13:00:56 -0700 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA06442 for ; Thu, 20 May 1999 13:00:50 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 3DB521E045; Thu, 20 May 1999 16:00:48 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id QAA05714; Thu, 20 May 1999 16:00:46 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.7/8.8.5) id QAA12215; Thu, 20 May 1999 16:00:46 -0400 (EDT) Message-Id: <199905202000.QAA12215@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: lwei@cisco.com Subject: Re: [Internet-Drafts@ietf.org: I-D ACTION:draft-ietf-pim-v2-dm-02.txt] Cc: pim@catarina.usc.edu Date: Thu, 20 May 1999 13:00:45 -0700 Versions: dmail (solaris) 2.2c/makemail 2.8t Sender: owner-pim@catarina.usc.edu Precedence: bulk This draft doesn't seem to have answered any of the outstanding PIM-DM issues that have been brought up over the past several months. None of the black holes that I pointed out appear to have been addressed. There are some open questions about packet processing - 2 that I remember: - where do you send a graft if you sent your prune with an upstream neighbour of 0.0.0.0? - what do you do with a Join that does not appear to be acting as a prune-override (e.g. your prune-override timer is not running for the source and group described in the Join)? Sections 5.3 and 7.8 still disagree about when to send Graft-ACKs. Section 5.2.1 is still very vague about what it means by "must not be sent...in response to each ... packet"; it could be interpreted to mean "must never be sent". I continue to think that this should be reworded. Several references to "deleting" an interface were changed to say "prune", however several references remain to "deleting" the interface so now it's even more confusing than it used to be. "negative cache entry" is defined in section 5 as an entry with no outgoing interfaces, and section 5.6 as an entry whose outgoing interfaces are all pruned. These definitions should be unified (and perhaps put in the glossary). The reference to the PIM-SM spec in section 7 is normative; thus this document can't progress to a state (e.g. Proposed) before the SM spec is in that state. This probably isn't desirable. Bill From owner-pim@catarina.usc.edu Thu May 20 16:58:51 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04245 for ; Thu, 20 May 1999 16:58:51 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA06639 for pim-list; Thu, 20 May 1999 13:49:08 -0700 Received: from nsa-mail.us.newbridge.com (nsa-mail.us.newbridge.com [209.58.11.226]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA06635 for ; Thu, 20 May 1999 13:49:03 -0700 Received: from nsa-gw1.us.newbridge.com (nsa-gw1 [209.58.11.225]) by nsa-mail.us.newbridge.com (8.9.3/8.9.3) with SMTP id QAA26587 for ; Thu, 20 May 1999 16:46:41 -0400 (EDT) Received: from herndon-mh1.us.newbridge.com by nsa-gw1.us.newbridge.com via smtpd (for nsa-mail.us.newbridge.com [209.58.11.226]) with SMTP; 20 May 1999 20:48:31 UT Received: from nsamail01.us.newbridge.com by herndon-mh1.us.newbridge.com with ESMTP; Thu, 20 May 1999 16:48:29 -0400 Received: from newbridge.com ([138.120.226.161]) by nsamail01.us.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA14BA for ; Thu, 20 May 1999 16:50:56 -0400 Message-Id: <37447295.BE11F7EB@newbridge.com> Date: Thu, 20 May 1999 16:37:41 -0400 From: Aman Devgan Organization: Newbridge Networks Corporation X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 CC: pim@catarina.usc.edu Subject: Re: [Internet-Drafts@ietf.org: I-D ACTION:draft-ietf-pim-v2-dm-02.txt] References: <199905202000.QAA12215@windsor.research.att.com> Content-Type: multipart/mixed; boundary="------------C4CDF564D28FD8BBCD3B3A18" Sender: owner-pim@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. --------------C4CDF564D28FD8BBCD3B3A18 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In section 5.2.1 that explains prune-override, the draft says that, "Other routers on the LAN will hear the prune message and respond with a join if they still expect multicast datagrams from the expected upstream router". Won't a "graft" instead of a "join" be more acurate? This will be in line with sections 7.4 and 7.7 . Aman --------------C4CDF564D28FD8BBCD3B3A18 Content-Type: text/x-vcard; charset=us-ascii; name="adevgan.vcf" Content-Description: Card for Aman Devgan Content-Disposition: attachment; filename="adevgan.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Devgan;Aman tel;fax:(703) 736-5959 tel;work:(703) 736-5853 x-mozilla-html:FALSE url:http://vivid-rnd.us.newbridge.com/~adevgan org:Newbridge Networks, Inc.;Internetworking Product Development adr:;;593 Herndon Parkway;Herndon;VA;20164;USA version:2.1 email;internet:adevgan@us.newbridge.com title:Design Engineer II x-mozilla-cpt:;0 fn:Aman Devgan end:vcard --------------C4CDF564D28FD8BBCD3B3A18-- From owner-pim@catarina.usc.edu Thu May 20 18:24:12 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05328 for ; Thu, 20 May 1999 18:24:11 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA06926 for pim-list; Thu, 20 May 1999 15:16:00 -0700 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id PAA06922 for ; Thu, 20 May 1999 15:15:54 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id RAA18568; Thu, 20 May 1999 17:01:18 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199905210001.RAA18568@dthaler.microsoft.com> Subject: Re: [Internet-Drafts@ietf.org: I-D ACTION:draft-ietf-pim-v2-dm-02.txt] In-Reply-To: <199905201711.KAA14673@flipper.cisco.com> from Liming Wei at "May 20, 1999 10:11:10 am" To: lwei@cisco.com (Liming Wei) Date: Thu, 20 May 1999 17:01:18 -0700 (PDT) Cc: pim@catarina.usc.edu X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Also, I'd like to solicit comments on the current PIM-SM draft. I have > collected past comments on the draft, both from messages on this list > and those sent to us/me in private. I plan to work on them in the next > week or so. I think most of them are of a clarification nature, and > can be done pretty quickly. Can you put a list of the points you've collected up on a web page? I've seen other WGs do this in the past with good results. Thanks, -Dave From owner-pim@catarina.usc.edu Thu May 20 18:40:10 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05516 for ; Thu, 20 May 1999 18:40:09 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA07020 for pim-list; Thu, 20 May 1999 15:33:34 -0700 Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id PAA07016 for ; Thu, 20 May 1999 15:33:29 -0700 Received: (lwei@localhost) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id PAA16320; Thu, 20 May 1999 15:32:27 -0700 (PDT) Date: Thu, 20 May 1999 15:32:27 -0700 (PDT) Message-Id: <199905202232.PAA16320@flipper.cisco.com> From: Liming Wei To: dthaler@dthaler.microsoft.com CC: pim@catarina.usc.edu In-reply-to: <199905210001.RAA18568@dthaler.microsoft.com> (message from Dave Thaler on Thu, 20 May 1999 17:01:18 -0700 (PDT)) Subject: Re: [Internet-Drafts@ietf.org: I-D ACTION:draft-ietf-pim-v2-dm-02.txt] Sender: owner-pim@catarina.usc.edu Precedence: bulk > From: Dave Thaler > > > Also, I'd like to solicit comments on the current PIM-SM draft. I have > > collected past comments on the draft, both from messages on this list > > and those sent to us/me in private. I plan to work on them in the next > > week or so. I think most of them are of a clarification nature, and > > can be done pretty quickly. > > Can you put a list of the points you've collected up on a web page? > I've seen other WGs do this in the past with good results. I will post a summary via email, and also attach it to the revised draft. The posting will be archieved at Tom's web site. Some of the messages were posted on the WG mailing list. The private messages may not be appropriate to be posted "as is". But I'll reword or do an abstract of the relevant ones, unless I'm explicitly told to not do so. -Liming From owner-pim@catarina.usc.edu Fri May 21 01:39:55 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA15071 for ; Fri, 21 May 1999 01:39:54 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id WAA08311 for pim-list; Thu, 20 May 1999 22:32:38 -0700 Received: from sirius.ctr.columbia.edu (root@sirius.ctr.columbia.edu [128.59.64.60]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id WAA08307 for ; Thu, 20 May 1999 22:32:32 -0700 Received: from comet.columbia.edu (argo.comet.columbia.edu [128.59.68.36]) by sirius.ctr.columbia.edu (8.9.1/8.6.4.287) with ESMTP id BAA27390; Fri, 21 May 1999 01:32:27 -0400 (EDT) Received: from localhost (xwang@localhost) by comet.columbia.edu (8.8.7/8.8.7/COMET) with SMTP id BAA11657; Fri, 21 May 1999 01:32:27 -0400 (EDT) X-Authentication-Warning: argo.comet.columbia.edu: xwang owned process doing -bs Date: Fri, 21 May 1999 01:32:26 -0400 (EDT) From: Xin Wang To: pim@catarina.usc.edu cc: Xin Wang Subject: Re:DR and IGMP Querier relation, and Assert In-Reply-To: <199903102318.PAA28642@flipper.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk I have some requestion regarding the DR router election, Assert triggering, as well as DR and IGMP Querier relation. 1. DR and IGMP Querier DR may or may not be the same router as the IGMP Querier. If more than one routers are connected to a LAN , the one with the highest IP address will be elected as DR, and the one with the lowest IP address will be elected as IGMP Querier. So if more than one routers on a LAN, DR and Querier will be different. In this case, are there actually two Queriers on a LAN soliciting group membership or DR only listens to the IGMP report that is solicited by the IGMP Querier? 2. DR election and Assert a) In PIM-SM, when a router is seleted as DR, it will set up multicast entries and sends Join/Prune etc. When two routers A , B and C are connected upstream to a LAN, Assert may be needed if more than one routers have multicast entries and have the LAN interface in their oif lists. Assume A is DR router. The problem is, how can a second router, say B, have multicast entry in the normal case? One case I can think of is becase the LAN has downstream routers and consider B as RPF router thus send Join. b) When Assert process settles, will any new Assert be triggered again afterwards? (assume no topology change and B is the Assert winner, thus no Assert timer is needed) Two possible cases I can consider: ------------------ If topology changes, router C is elected as new DR, it will trigger Assert to choose winner between C and B again. Thus each new DR election will trigger a Assert. Once the multicast entry in DR router A times out, it will create new entry, and will send join again. Data packets fowarding will trigger new Assert porcess. It seems the Assert is triggered periodically in this case. But from another angle, if Router B (forwarder) is down, will DR router A knows to send join right away, or it needs to wait for its entry times out? (with pruned oif, it won't send join. If LAN is the only interface in its oif, the entry may time out) Any other cases Assert will be triggered again? Thanks, Xin From owner-pim@catarina.usc.edu Fri May 21 01:57:41 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16225 for ; Fri, 21 May 1999 01:57:41 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id WAA08419 for pim-list; Thu, 20 May 1999 22:54:37 -0700 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id WAA08415 for ; Thu, 20 May 1999 22:54:32 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id E92504CE2E; Fri, 21 May 1999 01:54:30 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id BAA17047; Fri, 21 May 1999 01:54:30 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.7/8.8.5) id BAA16382; Fri, 21 May 1999 01:54:29 -0400 (EDT) Message-Id: <199905210554.BAA16382@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: xwang@comet.columbia.edu Subject: Re: DR and IGMP Querier relation, and Assert Cc: pim@catarina.usc.edu Date: Thu, 20 May 1999 22:54:28 -0700 Versions: dmail (solaris) 2.2c/makemail 2.8t Sender: owner-pim@catarina.usc.edu Precedence: bulk >In this case, are there actually two Queriers on a LAN soliciting >group membership or DR only listens to the IGMP report that is solicited >by the IGMP Querier? There is only one IGMP Querier; the DR acts as a Non-Querier. Bill From owner-pim@catarina.usc.edu Fri May 21 11:07:19 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01696 for ; Fri, 21 May 1999 11:07:19 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id HAA09802 for pim-list; Fri, 21 May 1999 07:55:34 -0700 Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id HAA09797 for ; Fri, 21 May 1999 07:55:16 -0700 Received: by NTSERVER1 with Internet Mail Service (5.0.1460.8) id ; Fri, 21 May 1999 10:54:46 -0400 Message-ID: From: Ravi Shekhar To: lwei@cisco.com, fenner@research.att.com Cc: pim@catarina.usc.edu Subject: RE: [Internet-Drafts@ietf.org: I-D ACTION:draft-ietf-pim-v2-dm-02 .txt] Date: Fri, 21 May 1999 10:54:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk I have two more comments to add: 1. When there are multiple downstream routers on a LAN which want to send prune up, shouldnt they use a random delay timer before sending it on the LAN (and suppress their prune if some other router has sent it with same prune-expiration time). Otherwise every time first data is flooded, there will be a prune generated by each downstream router on the LAN. This mechanism is already being used for prune-override joins in section 5.2.1. I think it would be good to extend it to prunes too. 2. In section 5.6 > The prune message sent upstream contains a holdtime. Its default value > is [Data-Timeout], .... Shouldnt the prune sent up have a holdtime value of "minimum of prune-expiration time of each pruned oif" - "current-time". If its value is 210 seconds, then network might get into vicious cycle of sending a prune up for 210 seconds, followed by a graft up to cancel it (as the preceeding paragraph in the draft seems to suggest). This could end up happening every 210 seconds (and will at least tripple the control traffic on pruned branches). It would be better to send a prune up with appropriate holdtime instead. - Ravi Shekhar. > > This draft doesn't seem to have answered any of the outstanding PIM-DM > issues that have been brought up over the past several months. > > None of the black holes that I pointed out appear to have been > addressed. > > There are some open questions about packet processing - 2 > that I remember: > - where do you send a graft if you sent your prune > with an upstream neighbour of 0.0.0.0? > - what do you do with a Join that does not appear to > be acting as a prune-override (e.g. your prune-override > timer is not running for the source and group described > in the Join)? > > Sections 5.3 and 7.8 still disagree about when to send Graft-ACKs. > > Section 5.2.1 is still very vague about what it means by "must not be > sent...in response to each ... packet"; it could be interpreted to > mean "must never be sent". I continue to think that this should be > reworded. > > Several references to "deleting" an interface were changed to say > "prune", however several references remain to "deleting" the interface > so now it's even more confusing than it used to be. > > "negative cache entry" is defined in section 5 as an entry with no > outgoing interfaces, and section 5.6 as an entry whose outgoing > interfaces are all pruned. These definitions should be unified > (and perhaps put in the glossary). > > The reference to the PIM-SM spec in section 7 is normative; thus this > document can't progress to a state (e.g. Proposed) before the SM > spec is in that state. This probably isn't desirable. > > Bill > From owner-pim@catarina.usc.edu Fri May 21 12:50:01 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03217 for ; Fri, 21 May 1999 12:50:00 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id JAA10143 for pim-list; Fri, 21 May 1999 09:36:41 -0700 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id JAA10139 for ; Fri, 21 May 1999 09:36:36 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 9E37D1E020; Fri, 21 May 1999 12:36:34 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id MAA00722; Fri, 21 May 1999 12:36:34 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.7/8.8.5) id MAA19691; Fri, 21 May 1999 12:36:33 -0400 (EDT) Message-Id: <199905211636.MAA19691@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rshekhar@redstonecom.com Subject: RE: [Internet-Drafts@ietf.org: I-D ACTION:draft-ietf-pim-v2-dm-02 .txt] Cc: lwei@cisco.com, pim@catarina.usc.edu Date: Fri, 21 May 1999 09:36:33 -0700 Versions: dmail (solaris) 2.2c/makemail 2.8t Sender: owner-pim@catarina.usc.edu Precedence: bulk Ravi, I discussed the upstream prune timer thing with Liming in Orlando (and suggested it on the mailing list; http://www3.juniper.net/~pusateri/pim/1998-html/0229.html). At that time, Liming said that the extra overhead was acceptable and he wanted to change the protocol as little as possible in order to get a PIM-DM RFC ASAP. Limiting overhead like this can be done in a backwards- compatible manner (and smart implementors can use it as a differentiator*), so it's reasonable to perhaps write a seperate spec. Bill * - if people chose their router purchase based upon PIM-DM implementation details, which I can't imagine they do (since there are much bigger differentiators) From owner-pim@catarina.usc.edu Fri May 21 14:12:16 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04370 for ; Fri, 21 May 1999 14:12:15 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA10548 for pim-list; Fri, 21 May 1999 10:57:45 -0700 Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA10543 for ; Fri, 21 May 1999 10:57:27 -0700 Received: by NTSERVER1 with Internet Mail Service (5.0.1460.8) id ; Fri, 21 May 1999 13:56:53 -0400 Message-ID: From: Ravi Shekhar To: Bill Fenner , Ravi Shekhar Cc: lwei@cisco.com, pim@catarina.usc.edu Subject: RE: [Internet-Drafts@ietf.org: I-D ACTION:draft-ietf-pim-v2-dm-02 .txt] Date: Fri, 21 May 1999 13:56:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk Bill, Yes, I remember that. And there were two possibilities cited - either every router keeps track of min prune time on the LAN or accepts whatever is stated in the upstream router's "schedule to prune" message [ following message by me in the same thread http://www3.juniper.net/~pusateri/pim/1998-html/0231.html ]. I wasnt aware that it has been postponed for later. I thought probably you missed it in your earlier mail. But thanks for clarifying. - Ravi Shekhar. > Ravi, > > I discussed the upstream prune timer thing with Liming in Orlando > (and suggested it on the mailing list; > http://www3.juniper.net/~pusateri/pim/1998-html/0229.html). > At that time, > Liming said that the extra overhead was acceptable and he > wanted to change > the protocol as little as possible in order to get a PIM-DM RFC ASAP. > Limiting overhead like this can be done in a backwards- compatible > manner (and smart implementors can use it as a > differentiator*), so it's > reasonable to perhaps write a seperate spec. > > Bill > > * - if people chose their router purchase based upon PIM-DM > implementation > details, which I can't imagine they do (since there are much bigger > differentiators) > From owner-pim@catarina.usc.edu Fri May 21 19:13:02 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08594 for ; Fri, 21 May 1999 19:13:01 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id QAA11455 for pim-list; Fri, 21 May 1999 16:09:47 -0700 Received: from sirius.ctr.columbia.edu (root@sirius.ctr.columbia.edu [128.59.64.60]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA11451 for ; Fri, 21 May 1999 16:09:41 -0700 Received: from comet.columbia.edu (argo.comet.columbia.edu [128.59.68.36]) by sirius.ctr.columbia.edu (8.9.1/8.6.4.287) with ESMTP id TAA29087; Fri, 21 May 1999 19:09:39 -0400 (EDT) Received: from localhost (xwang@localhost) by comet.columbia.edu (8.8.7/8.8.7/COMET) with SMTP id TAA14483; Fri, 21 May 1999 19:09:39 -0400 (EDT) X-Authentication-Warning: argo.comet.columbia.edu: xwang owned process doing -bs Date: Fri, 21 May 1999 19:09:38 -0400 (EDT) From: Xin Wang To: Bill Fenner cc: pim@catarina.usc.edu Subject: Re: DR election, Assert, and Failure recovery In-Reply-To: <199905210554.BAA16382@windsor.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk When a DR looses the Assert to another router, when will it send Join again? Will it trigger new Assert? If the last-hop router dies, how will PIM recover? Xin From owner-pim@catarina.usc.edu Tue May 25 09:00:41 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12107 for ; Tue, 25 May 1999 09:00:40 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id FAA21173 for pim-list; Tue, 25 May 1999 05:52:42 -0700 Received: from adn.alcatel.com ([198.205.32.33]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id FAA21169 for ; Tue, 25 May 1999 05:52:34 -0700 Received: from postal.adn.alcatel.com (postal [198.205.32.56]) by adn.alcatel.com with ESMTP (8.7.6/8.7.1) id IAA28837 for ; Tue, 25 May 1999 08:47:06 -0400 (EDT) Received: from adn.alcatel.com ([198.205.54.160]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA3987; Tue, 25 May 1999 08:53:09 -0400 Message-ID: <374A9D15.BC6524D2@adn.alcatel.com> Date: Tue, 25 May 1999 08:52:37 -0400 From: Liwen Wu Organization: Alcatel X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk, rsvp@isi.edu CC: liwen.wu@adn.alcatel.com Subject: Traffic Engineering for multicast traffic Content-Type: multipart/mixed; boundary="------------4971525D2938989A0185079B" Sender: owner-pim@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. --------------4971525D2938989A0185079B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have a couple of thoughts on multicast traffic engineering which I would like to receive comments on them: ------------------------------------------------------------------- Definition and Benefits ------------------------------------------------------------------- Multicast traffic engineering means that: a multicast forwarding tree is built through policies and explicited routed tree, instead of topology. Multicast traffic engineering can have similar benefits as unicast traffic engineering. It can be used to achieve efficient network resource utilization. ------------------------------------------------------------------- Methods ------------------------------------------------------------------- The multicast traffic engineering trees can be built by expanding the existing protocols. There are 2 categories of protocols: a) Receiver initiated tree setup: this kind of tree can have a large number of receivers and they join and prune quite frequently. PIM-SM protocol can be expanded to build this kind of tree. b) Sender initiated tree setup: this kind of tree can have limited number of receivers with very rare join and prune action. RSVP protocol can be expanded to build this kind of tree. MPLS label switching can be used to forward multicast traffic down the tree to avoid RPF checking ------------------------------------------------------------------- PIM-SM modifications for multicast traffic engineering ------------------------------------------------------------------- 1) The JOIN msg can be expanded to carry the explicited routed path towards the RP. A PIM-SM router always sends JOIN/PRUNE towards the upstream (parent) listed in the explicited routed path. 2) The JOIN msg can be expanded to carry a mpls label allocated by the downstream LSR. It can also carry other contraints, such as color, bandwidth etc. 3) A New msg JOIN-NAK can be sent from upstream(parent) to downstream(child) if the upstream can not satisfy the contraints listed in the JOIN msg. ------------------------------------------------------------------- RSVP modification for multicast traffic engineering ------------------------------------------------------------------- In addition to the extensions listed in 1) PATH can be expanded to carry the explicited routed tree. New semantics can be defined to reprensent explicited routed tree. If these ideas are acceptable, I would like to expand them to a internet draft. Thanks, Liwen-- --------------4971525D2938989A0185079B Content-Type: text/x-vcard; charset=us-ascii; name="liwen.wu.vcf" Content-Description: Card for Liwen Wu Content-Disposition: attachment; filename="liwen.wu.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Wu;Liwen tel;fax:703-724-2003 tel;work:703-724-2619 x-mozilla-html:FALSE org:Alcatel;R&D version:2.1 email;internet:liwen.wu@adn.alcatel.com adr;quoted-printable:;;44983 Knoll Square=0D=0A;Ashburn;VA;20147;U.S.A x-mozilla-cpt:;18304 fn:Liwen Wu end:vcard --------------4971525D2938989A0185079B-- From owner-pim@catarina.usc.edu Tue May 25 11:59:37 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22628 for ; Tue, 25 May 1999 11:59:36 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA21783 for pim-list; Tue, 25 May 1999 08:49:29 -0700 Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id IAA21779 for ; Tue, 25 May 1999 08:49:19 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 25 May 1999 16:48:52 +0100 To: Liwen Wu cc: mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk, rsvp@isi.edu Subject: Re: Traffic Engineering for multicast traffic In-reply-to: Your message of "Tue, 25 May 1999 08:52:37 EDT." <374A9D15.BC6524D2@adn.alcatel.com> Date: Tue, 25 May 1999 16:48:49 +0100 Message-ID: <1122.927647329@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-pim@catarina.usc.edu Precedence: bulk In message <374A9D15.BC6524D2@adn.alcatel.com>, Liwen Wu typed: there is already a small bodyo of work on QoS multicast routing which invovles some of these options - check out papers in ACM CCR by Carlberg, and papers in SIGCOMM and elsewhere by Faloutsos et al - see http://www.acm.org/sigcomm/sigcomm98/tp/abs_12.html for a link... >>------------------------------------------------------------------- >>PIM-SM modifications for multicast traffic engineering >>------------------------------------------------------------------- >> >>1) The JOIN msg can be expanded to carry the explicited routed path >>towards the RP. A PIM-SM router always sends JOIN/PRUNE towards >>the upstream (parent) listed in the explicited routed path. >> >>2) The JOIN msg can be expanded to carry a mpls label allocated by the >>downstream LSR. >>It can also carry other contraints, such as color, bandwidth etc. >> >>3) A New msg JOIN-NAK can be sent from upstream(parent) to >>downstream(child) >>if the upstream can not satisfy the contraints listed in the JOIN msg. >> >>------------------------------------------------------------------- >>RSVP modification for multicast traffic engineering >>------------------------------------------------------------------- >>In addition to the extensions listed in >> >> >>1) PATH can be expanded to carry the explicited routed tree. >>New semantics can be defined to reprensent explicited routed tree. >> >> >>If these ideas are acceptable, I would like to expand them to >>a internet draft. >> >>Thanks, >>Liwen-- >> >> >> >> >>--------------4971525D2938989A0185079B >>Content-Type: text/x-vcard; charset=us-ascii; >> name="liwen.wu.vcf" >>Content-Transfer-Encoding: 7bit >>Content-Description: Card for Liwen Wu >>Content-Disposition: attachment; >> filename="liwen.wu.vcf" >> >>begin:vcard >>n:Wu;Liwen >>tel;fax:703-724-2003 >>tel;work:703-724-2619 >>x-mozilla-html:FALSE >>org:Alcatel;R&D >>version:2.1 >>email;internet:liwen.wu@adn.alcatel.com >>adr;quoted-printable:;;44983 Knoll Square=0D=0A;Ashburn;VA;20147;U.S.A >>x-mozilla-cpt:;18304 >>fn:Liwen Wu >>end:vcard >> >>--------------4971525D2938989A0185079B-- >> cheers jon From owner-pim@catarina.usc.edu Tue May 25 13:38:23 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26136 for ; Tue, 25 May 1999 13:38:22 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA22115 for pim-list; Tue, 25 May 1999 10:15:06 -0700 Received: from yarilo.pluris.com (host66.pluris.com [208.227.9.66]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA22111 for ; Tue, 25 May 1999 10:14:57 -0700 Received: from akyol ([172.16.55.133]) by yarilo.pluris.com (8.9.2/8.9.1) with SMTP id KAA25091; Tue, 25 May 1999 10:14:13 -0700 (PDT) From: "Bora Akyol" To: "Liwen Wu" , , , , Subject: RE: Traffic Engineering for multicast traffic Date: Tue, 25 May 1999 10:15:39 -0700 Message-ID: <000501bea6d2$36717220$853710ac@pluris.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <374A9D15.BC6524D2@adn.alcatel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Liwen Can you please explain the differences between the way PIM-SM already works and your proposal? Also, what is performance gain obtained by using traffic engineered multicast trees vs standard trees. I can see the benefits of explicit routing for unicast, but in a dynamic multicast environment where locality of receivers may change rapidly, what benefits do the explicitly routed multicast trees buy the network operator? Regards Bora Akyol Pluris, http://www.pluris.com -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Liwen Wu Sent: Tuesday, May 25, 1999 5:53 AM To: mpls@UU.NET; pim@catarina.usc.edu; idmr@cs.ucl.ac.uk; rsvp@isi.edu Cc: liwen.wu@adn.alcatel.com Subject: Traffic Engineering for multicast traffic I have a couple of thoughts on multicast traffic engineering which I would like to receive comments on them: ------------------------------------------------------------------- Definition and Benefits ------------------------------------------------------------------- Multicast traffic engineering means that: a multicast forwarding tree is built through policies and explicited routed tree, instead of topology. Multicast traffic engineering can have similar benefits as unicast traffic engineering. It can be used to achieve efficient network resource utilization. ------------------------------------------------------------------- Methods ------------------------------------------------------------------- The multicast traffic engineering trees can be built by expanding the existing protocols. There are 2 categories of protocols: a) Receiver initiated tree setup: this kind of tree can have a large number of receivers and they join and prune quite frequently. PIM-SM protocol can be expanded to build this kind of tree. b) Sender initiated tree setup: this kind of tree can have limited number of receivers with very rare join and prune action. RSVP protocol can be expanded to build this kind of tree. MPLS label switching can be used to forward multicast traffic down the tree to avoid RPF checking ------------------------------------------------------------------- PIM-SM modifications for multicast traffic engineering ------------------------------------------------------------------- 1) The JOIN msg can be expanded to carry the explicited routed path towards the RP. A PIM-SM router always sends JOIN/PRUNE towards the upstream (parent) listed in the explicited routed path. 2) The JOIN msg can be expanded to carry a mpls label allocated by the downstream LSR. It can also carry other contraints, such as color, bandwidth etc. 3) A New msg JOIN-NAK can be sent from upstream(parent) to downstream(child) if the upstream can not satisfy the contraints listed in the JOIN msg. ------------------------------------------------------------------- RSVP modification for multicast traffic engineering ------------------------------------------------------------------- In addition to the extensions listed in 1) PATH can be expanded to carry the explicited routed tree. New semantics can be defined to reprensent explicited routed tree. If these ideas are acceptable, I would like to expand them to a internet draft. Thanks, Liwen-- From owner-pim@catarina.usc.edu Tue May 25 13:45:57 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26296 for ; Tue, 25 May 1999 13:45:56 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA22210 for pim-list; Tue, 25 May 1999 10:30:06 -0700 Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA22205 for ; Tue, 25 May 1999 10:29:50 -0700 Received: by NTSERVER1 with Internet Mail Service (5.0.1460.8) id ; Tue, 25 May 1999 13:29:12 -0400 Message-ID: From: Sanjay Wadhwa To: pim@catarina.usc.edu Cc: Sanjay Wadhwa Subject: Pim-dm assert.. Date: Tue, 25 May 1999 13:29:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi I have a question on pim-dm assert mechanism. Consider the following scenario : S | | A-L A-W | | ------------------------------- | D Lets say the assert-winner gets established at time t. The assert-loser will prune the interface to the lan till time t+210. Now if at time t+1 assert-winner loses route to the source. The downstream router potentially may not get any data till t+209. Does it make sense for the assert-winner in case it's route to source is lost, to trigger an Assert with metric infinity, on (non-pruned) OIFs in all (S,G) entries for this source. The assert loser will receive an Assert on the pruned interface, and since it's metric is better, can respond with an Assert, and remove prune state on that interface. Thanks Sanjay From owner-pim@catarina.usc.edu Tue May 25 14:22:59 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27175 for ; Tue, 25 May 1999 14:22:58 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA22391 for pim-list; Tue, 25 May 1999 11:09:58 -0700 Received: from adn.alcatel.com (postman.adn.alcatel.com [198.205.32.33]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA22385 for ; Tue, 25 May 1999 11:09:33 -0700 Received: from postal.adn.alcatel.com (postal [198.205.32.56]) by adn.alcatel.com with ESMTP (8.7.6/8.7.1) id OAA14152 for ; Tue, 25 May 1999 14:04:00 -0400 (EDT) Received: from adn.alcatel.com ([198.205.54.160]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA62E0; Tue, 25 May 1999 14:10:03 -0400 Message-ID: <374AE75C.B698F2F0@adn.alcatel.com> Date: Tue, 25 May 1999 14:09:32 -0400 From: Liwen Wu Organization: Alcatel X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Bora Akyol CC: mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk, rsvp@isi.edu Subject: Re: Traffic Engineering for multicast traffic References: <000501bea6d2$36717220$853710ac@pluris.com> Content-Type: multipart/mixed; boundary="------------A189965DB98ACFB4CCBF2C91" Sender: owner-pim@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. --------------A189965DB98ACFB4CCBF2C91 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Bora Akyol, Please see my replies embedded in your comments. Bora Akyol wrote: > Liwen > > Can you please explain the differences between the way PIM-SM already works > and > your proposal? A PIM-SM router, as far as I know today, join the upstream (parent) based on a unicast routing table(RPF checking). It is topology based. What I am proposing is that: 1) the receiver or a router (e.g border router) specify the whole reverse path along with the contraints(similar to the ones listed in Daniel O. Awduche's document) to RP and send the list along with the PIM JOIN msg towards RP. 2) the PIM-SM routers along this reverse path join the upstream according to the list specified in the PIM JOIN msg. Also, what is performance gain obtained by using traffic engineered > multicast trees vs standard trees. I can see the benefits of explicit > routing for unicast, but in a dynamic multicast environment where locality > of receivers may change rapidly, what benefits do the explicitly routed > multicast trees buy the network operator? The environment that I have in mind is backbone network, not the campus network. The benefits of explicit multicast trees over standard trees are very similar to the benefits of explicit traffic engineering tunnels. Here are a couple of them, there are maybe more: 1) If all the multicast trees in a backbone network are built by the topology, there is a possibility that some nodes/links are over congested, whereas other are not. 2) If a network wants to provide 2 different kinds of service, for example, premium service and best effort. For the premium service tree, the receiver may be able to specified the whole reverse path to RP which only contain premium capable nodes and links. And for the best effort tree, the receiver can join the upstream the same way as PIM-SM today. With the MPLS label forwarding, 2 kinds of multicast forwarding services are very easily achieved. best regards, Liwen-- > > > Regards > > Bora Akyol > Pluris, http://www.pluris.com > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Liwen Wu > Sent: Tuesday, May 25, 1999 5:53 AM > To: mpls@UU.NET; pim@catarina.usc.edu; idmr@cs.ucl.ac.uk; rsvp@isi.edu > Cc: liwen.wu@adn.alcatel.com > Subject: Traffic Engineering for multicast traffic > > I have a couple of thoughts on multicast traffic engineering which I > would > like to receive comments on them: > > ------------------------------------------------------------------- > Definition and Benefits > ------------------------------------------------------------------- > Multicast traffic engineering means that: a multicast forwarding tree > is built through policies and explicited routed tree, instead of > topology. > > Multicast traffic engineering can have similar benefits as unicast > traffic > engineering. It can be used to achieve efficient network resource > utilization. > > ------------------------------------------------------------------- > Methods > ------------------------------------------------------------------- > The multicast traffic engineering trees can be built by expanding the > existing protocols. There are 2 categories of protocols: > > a) Receiver initiated tree setup: this kind of tree can have > a large number of receivers and they join and prune quite frequently. > PIM-SM protocol can be expanded to build this kind of tree. > > b) Sender initiated tree setup: this kind of tree can have > limited number of receivers with very rare join and prune action. > RSVP protocol can be expanded to build this kind of tree. > > MPLS label switching can be used to forward multicast traffic down the > tree to avoid RPF checking > > ------------------------------------------------------------------- > PIM-SM modifications for multicast traffic engineering > ------------------------------------------------------------------- > > 1) The JOIN msg can be expanded to carry the explicited routed path > towards the RP. A PIM-SM router always sends JOIN/PRUNE towards > the upstream (parent) listed in the explicited routed path. > > 2) The JOIN msg can be expanded to carry a mpls label allocated by the > downstream LSR. > It can also carry other contraints, such as color, bandwidth etc. > > 3) A New msg JOIN-NAK can be sent from upstream(parent) to > downstream(child) > if the upstream can not satisfy the contraints listed in the JOIN msg. > > ------------------------------------------------------------------- > RSVP modification for multicast traffic engineering > ------------------------------------------------------------------- > In addition to the extensions listed in > > > 1) PATH can be expanded to carry the explicited routed tree. > New semantics can be defined to reprensent explicited routed tree. > > If these ideas are acceptable, I would like to expand them to > a internet draft. > > Thanks, > Liwen-- --------------A189965DB98ACFB4CCBF2C91 Content-Type: text/x-vcard; charset=us-ascii; name="liwen.wu.vcf" Content-Description: Card for Liwen Wu Content-Disposition: attachment; filename="liwen.wu.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Wu;Liwen tel;fax:703-724-2003 tel;work:703-724-2619 x-mozilla-html:FALSE org:Alcatel;R&D version:2.1 email;internet:liwen.wu@adn.alcatel.com adr;quoted-printable:;;44983 Knoll Square=0D=0A;Ashburn;VA;20147;U.S.A x-mozilla-cpt:;18304 fn:Liwen Wu end:vcard --------------A189965DB98ACFB4CCBF2C91-- From owner-pim@catarina.usc.edu Tue May 25 14:45:12 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27689 for ; Tue, 25 May 1999 14:45:11 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA22520 for pim-list; Tue, 25 May 1999 11:33:03 -0700 Received: from smtprtp.nortel.com ([192.122.117.66]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA22516 for ; Tue, 25 May 1999 11:32:41 -0700 Received: from zcard00n.ca.nortel.com (actually 47.116.0.118) by smtprtp.nortel.com; Tue, 25 May 1999 14:02:08 -0400 Received: from zcard008.bnr.ca (zcard008.ca.nortel.com [47.127.82.62]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id LSNZSA1G; Tue, 25 May 1999 14:01:55 -0400 Received: from nortel.com (zcars02x.ca.nortel.com [47.23.81.10]) by zcard008.bnr.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id LNKY123T; Tue, 25 May 1999 14:01:54 -0400 Message-ID: <374AE592.1D22E758@nortel.com> Date: Tue, 25 May 1999 14:01:54 -0400 From: "Cheng-Yin Lee" X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: Liwen Wu CC: mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk, rsvp@isi.edu Subject: Re: Traffic Engineering for multicast traffic References: <374A9D15.BC6524D2@adn.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Liwen Wu wrote: > I have a couple of thoughts on multicast traffic engineering which I > would > like to receive comments on them: i'm also inclined to use an explicit route towards the RP but less inclined to overload a routing protocol in this manner for traffic engineering. cheers, cyl > ------------------------------------------------------------------- > PIM-SM modifications for multicast traffic engineering > ------------------------------------------------------------------- > > 1) The JOIN msg can be expanded to carry the explicited routed path > towards the RP. A PIM-SM router always sends JOIN/PRUNE towards > the upstream (parent) listed in the explicited routed path. > > 2) The JOIN msg can be expanded to carry a mpls label allocated by the > downstream LSR. > It can also carry other contraints, such as color, bandwidth etc. > > 3) A New msg JOIN-NAK can be sent from upstream(parent) to > downstream(child) > if the upstream can not satisfy the contraints listed in the JOIN msg. From owner-pim@catarina.usc.edu Tue May 25 14:45:17 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27703 for ; Tue, 25 May 1999 14:45:16 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA22503 for pim-list; Tue, 25 May 1999 11:28:32 -0700 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA22499 for ; Tue, 25 May 1999 11:28:11 -0700 Received: from moo.isi.edu (moo.isi.edu [128.9.160.187]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA21091; Tue, 25 May 1999 11:27:58 -0700 (PDT) From: Anindo Banerjea Received: (from banerjea@localhost) by moo.isi.edu (8.8.7/8.8.6) id LAA17935; Tue, 25 May 1999 11:27:58 -0700 (PDT) Date: Tue, 25 May 1999 11:27:58 -0700 (PDT) Message-Id: <199905251827.LAA17935@moo.isi.edu> To: mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk, rsvp@isi.edu, liwen.wu@adn.alcatel.com Subject: Re: Traffic Engineering for multicast traffic X-Sun-Charset: US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk Here is a link to the Faloutsos et al paper. http://www.isi.edu/~banerjea/research/qosmic.ps There is also a more recent simulation paper showing the increase in the number of supportable applications for different QoS requirements for QoSMIC vs. PIM. http://www.isi.edu/~banerjea/research/rtaw99.pdf Anindo > From owner-idmr@cs.ucl.ac.uk Tue May 25 08:50:03 1999 > To: Liwen Wu > cc: mpls@uu.net, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk, rsvp@ISI.EDU > Subject: Re: Traffic Engineering for multicast traffic > Date: Tue, 25 May 1999 16:48:49 +0100 > From: Jon Crowcroft > X-Status: > > > In message <374A9D15.BC6524D2@adn.alcatel.com>, Liwen Wu typed: > > > there is already a small bodyo of work on QoS multicast routing which > invovles some of these options - check out papers in ACM CCR by > Carlberg, and papers in SIGCOMM and elsewhere by Faloutsos et al - see > http://www.acm.org/sigcomm/sigcomm98/tp/abs_12.html > for a link... > > >>------------------------------------------------------------------- > >>PIM-SM modifications for multicast traffic engineering > >>------------------------------------------------------------------- > >> > >>1) The JOIN msg can be expanded to carry the explicited routed path > >>towards the RP. A PIM-SM router always sends JOIN/PRUNE towards > >>the upstream (parent) listed in the explicited routed path. > >> > >>2) The JOIN msg can be expanded to carry a mpls label allocated by the > >>downstream LSR. > >>It can also carry other contraints, such as color, bandwidth etc. > >> > >>3) A New msg JOIN-NAK can be sent from upstream(parent) to > >>downstream(child) > >>if the upstream can not satisfy the contraints listed in the JOIN msg. > >> > >>------------------------------------------------------------------- > >>RSVP modification for multicast traffic engineering > >>------------------------------------------------------------------- > >>In addition to the extensions listed in > >> > >> > >>1) PATH can be expanded to carry the explicited routed tree. > >>New semantics can be defined to reprensent explicited routed tree. > >> > >> > >>If these ideas are acceptable, I would like to expand them to > >>a internet draft. > >> > >>Thanks, > >>Liwen-- > >> > >> > >> > >> > >>--------------4971525D2938989A0185079B > >>Content-Type: text/x-vcard; charset=us-ascii; > >> name="liwen.wu.vcf" > >>Content-Transfer-Encoding: 7bit > >>Content-Description: Card for Liwen Wu > >>Content-Disposition: attachment; > >> filename="liwen.wu.vcf" > >> > >>begin:vcard > >>n:Wu;Liwen > >>tel;fax:703-724-2003 > >>tel;work:703-724-2619 > >>x-mozilla-html:FALSE > >>org:Alcatel;R&D > >>version:2.1 > >>email;internet:liwen.wu@adn.alcatel.com > >>adr;quoted-printable:;;44983 Knoll Square=0D=0A;Ashburn;VA;20147;U.S.A > >>x-mozilla-cpt:;18304 > >>fn:Liwen Wu > >>end:vcard > >> > >>--------------4971525D2938989A0185079B-- > >> > > cheers > > jon > > From owner-pim@catarina.usc.edu Tue May 25 16:33:51 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29647 for ; Tue, 25 May 1999 16:33:51 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA23094 for pim-list; Tue, 25 May 1999 13:26:48 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA22905 for ; Tue, 25 May 1999 12:38:26 -0700 From: Masataka Ohta Message-Id: <199905251923.EAA08510@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id EAA08510; Wed, 26 May 1999 04:23:39 +0900 Subject: RE: Traffic Engineering for multicast traffic To: joel@mcquillan.com (Joel Halpern) Date: Wed, 26 May 99 4:23:39 JST Cc: venki@lucent.com, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk In-Reply-To: ; from "Joel Halpern" at May 25, 99 2:48 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-pim@catarina.usc.edu Precedence: bulk Joel; > For example, one mechanism would be to allow the path to be overridden > once you arrived at the tree. That is, once the join reaches an on-tree > router, there is no poin in creating a second path from there to the > root. So simply stop. A variation on this technique was used with PNNI > support for ATM Leaf Initiated Joins for pt-to-multipoint. > There are some problems with this, and probably some better refinements. > But the fundemental observation is that there is no reason to have the > multicast packets take two paths from the root to another spot on the > tree. Some one path will suffice. Picking which one may be harder than > just "accepting the first". Are you aware of the fundamental observation that PNNI is not used in the real world? Masataka Ohta From owner-pim@catarina.usc.edu Tue May 25 16:33:52 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29646 for ; Tue, 25 May 1999 16:33:51 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA23118 for pim-list; Tue, 25 May 1999 13:28:30 -0700 Received: from yarilo.pluris.com ([208.227.9.66]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA22957 for ; Tue, 25 May 1999 12:58:52 -0700 Received: from akyol ([172.16.55.133]) by yarilo.pluris.com (8.9.2/8.9.1) with SMTP id MAA01102; Tue, 25 May 1999 12:58:14 -0700 (PDT) From: "Bora Akyol" To: "Liwen Wu" , "r. venkateswaran" Cc: , Subject: RE: Traffic Engineering for multicast traffic Date: Tue, 25 May 1999 12:59:09 -0700 Message-ID: <000301bea6e9$0d363640$853710ac@pluris.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <374AFA71.96A9CE7C@adn.alcatel.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit See my comments within: > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Liwen Wu > Sent: Tuesday, May 25, 1999 12:31 PM > To: r. venkateswaran > Cc: Bora Akyol; mpls@UU.NET; pim@catarina.usc.edu; idmr@cs.ucl.ac.uk; > rsvp@isi.edu > Subject: Re: Traffic Engineering for multicast traffic > > > Hello Venki, > > Thanks for raising a very good point. > > Here is my explaination: > > 1) In terms of "a bunch of unicast paths to the receivers...", > > When a PIM-SM router receives a JOIN msg which includes > a reverse explicit path and contraints, the router is ALREADY > on the tree, ALSO the router and the current tree is able to satisfy > the contraints(e.g. delay, bandwidth etc) specified in the JOIN msg, > the router should not send a join to a different parent. If the current > tree is NOT able to satisfy the contraints and the reverse explicit path > is different than the one specified in the JOIN msg, then the router > can JOIN a different parent. Once the JOIN all the way to > RP is complete, this router can prune the current tree and use the > new tree. To konw whether the router has JOIN all the way through > new reverse path to RP, incoming data or a NEW PIM ACK msg can > be used. > > 2) In terms of "loop", > > All the nodes, keeps the reverse explicit path as part of the > state or context > of the tree.Once the tree is stablized, there should be one > reverse explicit path > per tree. Each JOIN also contains the desired reverse explicit path to RP. > With these 2 explicit paths, the PIM-SM router can very easily detect the > "loop" and send the NEW PIM NAK msg downstream. > > best regards, > Liwen-- So does this mean that every time the network topology changes, some process will need to update the state associated with all multicast sessions on every node. I would still assert that even in the backbone routers, I would rather not circumvent IP routing by creating offline-crafted explicitly routed multicast trees. If we are to do something about a problem, that I am not sure exists, why don't we change the multicast routing to do something similar to OSPF(ISIS)-OMP proposed by C. Villamizar or by implemented in the ARPANET by BBN (See SIGCOMM 89 Zinky, Khanna) for multicast instead of unicast: That is, let us make the multicast routing sensitive to both topology and network utilization. This way, no explicit routing will be necessary. The problem statement that you have mentioned then becomes: Multicast routing must be sensitive to the utilization of the network while creating multicast trees. If network statistics as well as network topology are available (such as in OSPF-OMP) then one can create the multicast tree based on both of these factors, and avoid unnecessary congestion and hot spotting in the network. Such algorithms can work either in Layer 2 or in Layer 3. Regards Bora Akyol Pluris, http://www.pluris.com > > "R. Venkateswaran" wrote: > > > Hi Liwen, > > > > > What I am proposing is that: > > > > > > 1) the receiver or a router (e.g border router) specify the > whole reverse path > > > along with the contraints(similar to the ones listed in > Daniel O. Awduche's > > > document) to RP and send the list along with the PIM JOIN msg > towards RP. > > > > > > 2) the PIM-SM routers along this reverse path join the > upstream according to > > > the list > > > specified in the PIM JOIN msg. > > > > > > > I see some serious problems with this approach. The main concern is > > that the resulting "multicast tree" may no longer be a "tree" by > > graph-theory definitions. That is, an intermediate router will receive > > the same multicast data on more than one incoming link and will have > > to forward them multiple times to different receivers because each > > receiver wants a certain path for their data. Eventually, you may end > > up with a bunch of unicast paths to the receivers, as opposed to a > > multicast tree. > > > > To eliminate these "loops" in the multicast tree, some node > > has to remember the entire multicast tree structure and eliminate > > duplicate paths at the time of PIM JOIN. I would assume it would be > > the RP that has to maintain this information. For large networks, > > this will involve too much of state information for the RP to > > maintain. > > > > Regards, > > venki > > > > Disclaimer: The above comments are personal views, and may not > > necessarily reflect those of my organization. > > -- > > R. Venkateswaran (Venki) [email -> mailto:venki@lucent.com ] > > [Lucent Technologies Bell Labs (IHP), Room 2E-241,Ph # (630)-979-6253] > From owner-pim@catarina.usc.edu Tue May 25 16:35:48 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29703 for ; Tue, 25 May 1999 16:35:48 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA23243 for pim-list; Tue, 25 May 1999 13:30:34 -0700 Received: from auemlsrv.firewall.lucent.com ([192.11.223.161]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA22776 for ; Tue, 25 May 1999 12:15:56 -0700 Received: from ihgp3.ih.lucent.com (h135-1-27-103.lucent.com [135.1.27.103]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA13763 for ; Tue, 25 May 1999 15:15:55 -0400 (EDT) Received: by ihgp3.ih.lucent.com (8.8.8+Sun/EMS-1.4 sol2) id OAA09321; Tue, 25 May 1999 14:15:44 -0500 (CDT) Cc: pim@catarina.usc.edu, idmr@cs.ucl.ac.uk Received: from il0015venki1.ih.lucent.com by ihgp3.ih.lucent.com (8.8.8+Sun/EMS-1.4 sol2) id OAA09241; Tue, 25 May 1999 14:15:36 -0500 (CDT) Date: Tue, 25 May 1999 14:15:49 -0500 (Central Daylight Time) From: "R. Venkateswaran" Reply-To: "r. venkateswaran" To: Joel Halpern Original-cc: pim@catarina.usc.edu, idmr@cs.ucl.ac.uk Subject: RE: Traffic Engineering for multicast traffic In-Reply-To: Message-ID: X-X-Sender: venki@ihgp3.ih.lucent.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk On Tue, 25 May 1999, Joel Halpern wrote: > There are some problems with this, and probably some better refinements. > > But the fundemental observation is that there is no reason to have the > multicast packets take two paths from the root to another spot on the > tree. Some one path will suffice. Picking which one may be harder than > just "accepting the first". > Yes, the problem here is that each node now has to remember the explicit path from itself to the root. Otherwise, it cannot decide whether a new requested explicit path (in a new PIM JOIN message) to the root is "better" or "worse" than the existing path. Further, if the node decides that the new explicit pathi is "better", it has to then convey this information to all the downstream routers on the multicast tree, because each node now has to update its explicit path to the root. Regards, venki Disclaimer: The above comments are personal views, and may not necessarily reflect those of my organization. -- R. Venkateswaran (Venki) [email -> mailto:venki@lucent.com ] [Lucent Technologies Bell Labs (IHP), Room 2E-241,Ph # (630)-979-6253] From owner-pim@catarina.usc.edu Tue May 25 16:39:35 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29731 for ; Tue, 25 May 1999 16:39:35 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA23106 for pim-list; Tue, 25 May 1999 13:28:18 -0700 Received: from adn.alcatel.com ([198.205.32.33]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA22856 for ; Tue, 25 May 1999 12:30:51 -0700 Received: from postal.adn.alcatel.com (postal [198.205.32.56]) by adn.alcatel.com with ESMTP (8.7.6/8.7.1) id PAA17545 for ; Tue, 25 May 1999 15:25:25 -0400 (EDT) Received: from adn.alcatel.com ([198.205.54.160]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA6C97; Tue, 25 May 1999 15:31:27 -0400 Message-ID: <374AFA71.96A9CE7C@adn.alcatel.com> Date: Tue, 25 May 1999 15:30:57 -0400 From: Liwen Wu Organization: Alcatel X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "r. venkateswaran" CC: Bora Akyol , mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk, rsvp@isi.edu Subject: Re: Traffic Engineering for multicast traffic References: Content-Type: multipart/mixed; boundary="------------CAEF4BCEEDFF5B2458ED4733" Sender: owner-pim@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. --------------CAEF4BCEEDFF5B2458ED4733 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Venki, Thanks for raising a very good point. Here is my explaination: 1) In terms of "a bunch of unicast paths to the receivers...", When a PIM-SM router receives a JOIN msg which includes a reverse explicit path and contraints, the router is ALREADY on the tree, ALSO the router and the current tree is able to satisfy the contraints(e.g. delay, bandwidth etc) specified in the JOIN msg, the router should not send a join to a different parent. If the current tree is NOT able to satisfy the contraints and the reverse explicit path is different than the one specified in the JOIN msg, then the router can JOIN a different parent. Once the JOIN all the way to RP is complete, this router can prune the current tree and use the new tree. To konw whether the router has JOIN all the way through new reverse path to RP, incoming data or a NEW PIM ACK msg can be used. 2) In terms of "loop", All the nodes, keeps the reverse explicit path as part of the state or context of the tree.Once the tree is stablized, there should be one reverse explicit path per tree. Each JOIN also contains the desired reverse explicit path to RP. With these 2 explicit paths, the PIM-SM router can very easily detect the "loop" and send the NEW PIM NAK msg downstream. best regards, Liwen-- "R. Venkateswaran" wrote: > Hi Liwen, > > > What I am proposing is that: > > > > 1) the receiver or a router (e.g border router) specify the whole reverse path > > along with the contraints(similar to the ones listed in Daniel O. Awduche's > > document) to RP and send the list along with the PIM JOIN msg towards RP. > > > > 2) the PIM-SM routers along this reverse path join the upstream according to > > the list > > specified in the PIM JOIN msg. > > > > I see some serious problems with this approach. The main concern is > that the resulting "multicast tree" may no longer be a "tree" by > graph-theory definitions. That is, an intermediate router will receive > the same multicast data on more than one incoming link and will have > to forward them multiple times to different receivers because each > receiver wants a certain path for their data. Eventually, you may end > up with a bunch of unicast paths to the receivers, as opposed to a > multicast tree. > > To eliminate these "loops" in the multicast tree, some node > has to remember the entire multicast tree structure and eliminate > duplicate paths at the time of PIM JOIN. I would assume it would be > the RP that has to maintain this information. For large networks, > this will involve too much of state information for the RP to > maintain. > > Regards, > venki > > Disclaimer: The above comments are personal views, and may not > necessarily reflect those of my organization. > -- > R. Venkateswaran (Venki) [email -> mailto:venki@lucent.com ] > [Lucent Technologies Bell Labs (IHP), Room 2E-241,Ph # (630)-979-6253] --------------CAEF4BCEEDFF5B2458ED4733 Content-Type: text/x-vcard; charset=us-ascii; name="liwen.wu.vcf" Content-Description: Card for Liwen Wu Content-Disposition: attachment; filename="liwen.wu.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Wu;Liwen tel;fax:703-724-2003 tel;work:703-724-2619 x-mozilla-html:FALSE org:Alcatel;R&D version:2.1 email;internet:liwen.wu@adn.alcatel.com adr;quoted-printable:;;44983 Knoll Square=0D=0A;Ashburn;VA;20147;U.S.A x-mozilla-cpt:;18304 fn:Liwen Wu end:vcard --------------CAEF4BCEEDFF5B2458ED4733-- From owner-pim@catarina.usc.edu Tue May 25 16:54:32 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29919 for ; Tue, 25 May 1999 16:54:32 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA23390 for pim-list; Tue, 25 May 1999 13:46:49 -0700 Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA23386 for ; Tue, 25 May 1999 13:46:44 -0700 Received: from ihgp3.ih.lucent.com (h135-1-27-103.lucent.com [135.1.27.103]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA16376 for ; Tue, 25 May 1999 16:46:43 -0400 (EDT) Received: by ihgp3.ih.lucent.com (8.8.8+Sun/EMS-1.4 sol2) id PAA17766; Tue, 25 May 1999 15:46:32 -0500 (CDT) Cc: Bora Akyol , mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk, rsvp@isi.edu Received: from il0015venki1.ih.lucent.com by ihgp3.ih.lucent.com (8.8.8+Sun/EMS-1.4 sol2) id PAA17503; Tue, 25 May 1999 15:46:21 -0500 (CDT) Date: Tue, 25 May 1999 15:46:31 -0500 (Central Daylight Time) From: "R. Venkateswaran" Reply-To: "r. venkateswaran" To: Liwen Wu Original-cc: Bora Akyol , mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk, rsvp@isi.edu Subject: Re: Traffic Engineering for multicast traffic In-Reply-To: <374AFA71.96A9CE7C@adn.alcatel.com> Message-ID: X-X-Sender: venki@ihgp3.ih.lucent.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi Liwen, On Tue, 25 May 1999, Liwen Wu wrote: > When a PIM-SM router receives a JOIN msg which includes > a reverse explicit path and contraints, the router is ALREADY > on the tree, ALSO the router and the current tree is able to satisfy > the contraints(e.g. delay, bandwidth etc) specified in the JOIN msg, > the router should not send a join to a different parent. If the current > tree is NOT able to satisfy the contraints and the reverse explicit path > is different than the one specified in the JOIN msg, then the router > can JOIN a different parent. Once the JOIN all the way to > RP is complete, this router can prune the current tree and use the > new tree. To konw whether the router has JOIN all the way through > new reverse path to RP, incoming data or a NEW PIM ACK msg can > be used. Please also note that since each node is maintaining the reverse explicit path to the RP (your point 2 below), the router must ALSO send this updated reverse path information to ALL the downstream routers which are part of the multicast tree. So, your JOIN will be complete only when the information has traversed to every router in the multicast tree. Further complications arise when another receiver tries to JOIN a downstream PIM-SM router before the updated reverse path information has traversed to this downstream router. How does it then detect "loops"? Such a scenario is quite common for a dynamic multicast session where receivers join/leave the multicast group frequently. > 2) In terms of "loop", > > All the nodes, keeps the reverse explicit path as part of the state or context > of the tree.Once the tree is stablized, there should be one reverse explicit path > per tree. Each JOIN also contains the desired reverse explicit path to RP. > With these 2 explicit paths, the PIM-SM router can very easily detect the > "loop" and send the NEW PIM NAK msg downstream. Regards, venki Disclaimer: The above comments are personal views, and may not necessarily reflect those of my organization. -- R. Venkateswaran (Venki) [email -> mailto:venki@lucent.com ] [Lucent Technologies Bell Labs (IHP), Room 2E-241,Ph # (630)-979-6253] From owner-pim@catarina.usc.edu Tue May 25 17:36:58 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00531 for ; Tue, 25 May 1999 17:36:56 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA22835 for pim-list; Tue, 25 May 1999 12:26:27 -0700 Received: from auemlsrv.firewall.lucent.com ([192.11.223.161]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA22776 for ; Tue, 25 May 1999 12:15:56 -0700 Received: from ihgp3.ih.lucent.com (h135-1-27-103.lucent.com [135.1.27.103]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA13763 for ; Tue, 25 May 1999 15:15:55 -0400 (EDT) Received: by ihgp3.ih.lucent.com (8.8.8+Sun/EMS-1.4 sol2) id OAA09321; Tue, 25 May 1999 14:15:44 -0500 (CDT) Cc: pim@catarina.usc.edu, idmr@cs.ucl.ac.uk Received: from il0015venki1.ih.lucent.com by ihgp3.ih.lucent.com (8.8.8+Sun/EMS-1.4 sol2) id OAA09241; Tue, 25 May 1999 14:15:36 -0500 (CDT) Date: Tue, 25 May 1999 14:15:49 -0500 (Central Daylight Time) From: "R. Venkateswaran" Reply-To: "r. venkateswaran" To: Joel Halpern Original-cc: pim@catarina.usc.edu, idmr@cs.ucl.ac.uk Subject: RE: Traffic Engineering for multicast traffic In-Reply-To: Message-ID: X-X-Sender: venki@ihgp3.ih.lucent.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk On Tue, 25 May 1999, Joel Halpern wrote: > There are some problems with this, and probably some better refinements. > > But the fundemental observation is that there is no reason to have the > multicast packets take two paths from the root to another spot on the > tree. Some one path will suffice. Picking which one may be harder than > just "accepting the first". > Yes, the problem here is that each node now has to remember the explicit path from itself to the root. Otherwise, it cannot decide whether a new requested explicit path (in a new PIM JOIN message) to the root is "better" or "worse" than the existing path. Further, if the node decides that the new explicit pathi is "better", it has to then convey this information to all the downstream routers on the multicast tree, because each node now has to update its explicit path to the root. Regards, venki Disclaimer: The above comments are personal views, and may not necessarily reflect those of my organization. -- R. Venkateswaran (Venki) [email -> mailto:venki@lucent.com ] [Lucent Technologies Bell Labs (IHP), Room 2E-241,Ph # (630)-979-6253] From owner-pim@catarina.usc.edu Tue May 25 17:44:49 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00579 for ; Tue, 25 May 1999 17:44:48 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id OAA23621 for pim-list; Tue, 25 May 1999 14:33:35 -0700 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA23617 for ; Tue, 25 May 1999 14:33:31 -0700 Received: from moo.isi.edu (moo.isi.edu [128.9.160.187]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA10561; Tue, 25 May 1999 14:33:27 -0700 (PDT) From: Anindo Banerjea Received: (from banerjea@localhost) by moo.isi.edu (8.8.7/8.8.6) id OAA18065; Tue, 25 May 1999 14:33:27 -0700 (PDT) Date: Tue, 25 May 1999 14:33:27 -0700 (PDT) Message-Id: <199905252133.OAA18065@moo.isi.edu> To: joel@mcquillan.com, venki@lucent.com Subject: RE: Traffic Engineering for multicast traffic Cc: pim@catarina.usc.edu, idmr@cs.ucl.ac.uk X-Sun-Charset: US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk See http://www.isi.edu/~banerjea/research/qosmic.ps for one solution to this problems of needing to keep explicit topology of the entire tree. Anindo From owner-pim@catarina.usc.edu Tue May 25 17:44:50 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00592 for ; Tue, 25 May 1999 17:44:49 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA22909 for pim-list; Tue, 25 May 1999 12:38:31 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA22905 for ; Tue, 25 May 1999 12:38:26 -0700 From: Masataka Ohta Message-Id: <199905251923.EAA08510@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id EAA08510; Wed, 26 May 1999 04:23:39 +0900 Subject: RE: Traffic Engineering for multicast traffic To: joel@mcquillan.com (Joel Halpern) Date: Wed, 26 May 99 4:23:39 JST Cc: venki@lucent.com, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk In-Reply-To: ; from "Joel Halpern" at May 25, 99 2:48 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-pim@catarina.usc.edu Precedence: bulk Joel; > For example, one mechanism would be to allow the path to be overridden > once you arrived at the tree. That is, once the join reaches an on-tree > router, there is no poin in creating a second path from there to the > root. So simply stop. A variation on this technique was used with PNNI > support for ATM Leaf Initiated Joins for pt-to-multipoint. > There are some problems with this, and probably some better refinements. > But the fundemental observation is that there is no reason to have the > multicast packets take two paths from the root to another spot on the > tree. Some one path will suffice. Picking which one may be harder than > just "accepting the first". Are you aware of the fundamental observation that PNNI is not used in the real world? Masataka Ohta From owner-pim@catarina.usc.edu Tue May 25 18:05:22 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00792 for ; Tue, 25 May 1999 18:05:21 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA22961 for pim-list; Tue, 25 May 1999 12:58:56 -0700 Received: from yarilo.pluris.com ([208.227.9.66]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA22957 for ; Tue, 25 May 1999 12:58:52 -0700 Received: from akyol ([172.16.55.133]) by yarilo.pluris.com (8.9.2/8.9.1) with SMTP id MAA01102; Tue, 25 May 1999 12:58:14 -0700 (PDT) From: "Bora Akyol" To: "Liwen Wu" , "r. venkateswaran" Cc: , Subject: RE: Traffic Engineering for multicast traffic Date: Tue, 25 May 1999 12:59:09 -0700 Message-ID: <000301bea6e9$0d363640$853710ac@pluris.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <374AFA71.96A9CE7C@adn.alcatel.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit See my comments within: > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Liwen Wu > Sent: Tuesday, May 25, 1999 12:31 PM > To: r. venkateswaran > Cc: Bora Akyol; mpls@UU.NET; pim@catarina.usc.edu; idmr@cs.ucl.ac.uk; > rsvp@isi.edu > Subject: Re: Traffic Engineering for multicast traffic > > > Hello Venki, > > Thanks for raising a very good point. > > Here is my explaination: > > 1) In terms of "a bunch of unicast paths to the receivers...", > > When a PIM-SM router receives a JOIN msg which includes > a reverse explicit path and contraints, the router is ALREADY > on the tree, ALSO the router and the current tree is able to satisfy > the contraints(e.g. delay, bandwidth etc) specified in the JOIN msg, > the router should not send a join to a different parent. If the current > tree is NOT able to satisfy the contraints and the reverse explicit path > is different than the one specified in the JOIN msg, then the router > can JOIN a different parent. Once the JOIN all the way to > RP is complete, this router can prune the current tree and use the > new tree. To konw whether the router has JOIN all the way through > new reverse path to RP, incoming data or a NEW PIM ACK msg can > be used. > > 2) In terms of "loop", > > All the nodes, keeps the reverse explicit path as part of the > state or context > of the tree.Once the tree is stablized, there should be one > reverse explicit path > per tree. Each JOIN also contains the desired reverse explicit path to RP. > With these 2 explicit paths, the PIM-SM router can very easily detect the > "loop" and send the NEW PIM NAK msg downstream. > > best regards, > Liwen-- So does this mean that every time the network topology changes, some process will need to update the state associated with all multicast sessions on every node. I would still assert that even in the backbone routers, I would rather not circumvent IP routing by creating offline-crafted explicitly routed multicast trees. If we are to do something about a problem, that I am not sure exists, why don't we change the multicast routing to do something similar to OSPF(ISIS)-OMP proposed by C. Villamizar or by implemented in the ARPANET by BBN (See SIGCOMM 89 Zinky, Khanna) for multicast instead of unicast: That is, let us make the multicast routing sensitive to both topology and network utilization. This way, no explicit routing will be necessary. The problem statement that you have mentioned then becomes: Multicast routing must be sensitive to the utilization of the network while creating multicast trees. If network statistics as well as network topology are available (such as in OSPF-OMP) then one can create the multicast tree based on both of these factors, and avoid unnecessary congestion and hot spotting in the network. Such algorithms can work either in Layer 2 or in Layer 3. Regards Bora Akyol Pluris, http://www.pluris.com > > "R. Venkateswaran" wrote: > > > Hi Liwen, > > > > > What I am proposing is that: > > > > > > 1) the receiver or a router (e.g border router) specify the > whole reverse path > > > along with the contraints(similar to the ones listed in > Daniel O. Awduche's > > > document) to RP and send the list along with the PIM JOIN msg > towards RP. > > > > > > 2) the PIM-SM routers along this reverse path join the > upstream according to > > > the list > > > specified in the PIM JOIN msg. > > > > > > > I see some serious problems with this approach. The main concern is > > that the resulting "multicast tree" may no longer be a "tree" by > > graph-theory definitions. That is, an intermediate router will receive > > the same multicast data on more than one incoming link and will have > > to forward them multiple times to different receivers because each > > receiver wants a certain path for their data. Eventually, you may end > > up with a bunch of unicast paths to the receivers, as opposed to a > > multicast tree. > > > > To eliminate these "loops" in the multicast tree, some node > > has to remember the entire multicast tree structure and eliminate > > duplicate paths at the time of PIM JOIN. I would assume it would be > > the RP that has to maintain this information. For large networks, > > this will involve too much of state information for the RP to > > maintain. > > > > Regards, > > venki > > > > Disclaimer: The above comments are personal views, and may not > > necessarily reflect those of my organization. > > -- > > R. Venkateswaran (Venki) [email -> mailto:venki@lucent.com ] > > [Lucent Technologies Bell Labs (IHP), Room 2E-241,Ph # (630)-979-6253] > From owner-pim@catarina.usc.edu Tue May 25 18:06:50 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00808 for ; Tue, 25 May 1999 18:06:49 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA22860 for pim-list; Tue, 25 May 1999 12:30:57 -0700 Received: from adn.alcatel.com ([198.205.32.33]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA22856 for ; Tue, 25 May 1999 12:30:51 -0700 Received: from postal.adn.alcatel.com (postal [198.205.32.56]) by adn.alcatel.com with ESMTP (8.7.6/8.7.1) id PAA17545 for ; Tue, 25 May 1999 15:25:25 -0400 (EDT) Received: from adn.alcatel.com ([198.205.54.160]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA6C97; Tue, 25 May 1999 15:31:27 -0400 Message-ID: <374AFA71.96A9CE7C@adn.alcatel.com> Date: Tue, 25 May 1999 15:30:57 -0400 From: Liwen Wu Organization: Alcatel X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "r. venkateswaran" CC: Bora Akyol , mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk, rsvp@isi.edu Subject: Re: Traffic Engineering for multicast traffic References: Content-Type: multipart/mixed; boundary="------------CAEF4BCEEDFF5B2458ED4733" Sender: owner-pim@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. --------------CAEF4BCEEDFF5B2458ED4733 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Venki, Thanks for raising a very good point. Here is my explaination: 1) In terms of "a bunch of unicast paths to the receivers...", When a PIM-SM router receives a JOIN msg which includes a reverse explicit path and contraints, the router is ALREADY on the tree, ALSO the router and the current tree is able to satisfy the contraints(e.g. delay, bandwidth etc) specified in the JOIN msg, the router should not send a join to a different parent. If the current tree is NOT able to satisfy the contraints and the reverse explicit path is different than the one specified in the JOIN msg, then the router can JOIN a different parent. Once the JOIN all the way to RP is complete, this router can prune the current tree and use the new tree. To konw whether the router has JOIN all the way through new reverse path to RP, incoming data or a NEW PIM ACK msg can be used. 2) In terms of "loop", All the nodes, keeps the reverse explicit path as part of the state or context of the tree.Once the tree is stablized, there should be one reverse explicit path per tree. Each JOIN also contains the desired reverse explicit path to RP. With these 2 explicit paths, the PIM-SM router can very easily detect the "loop" and send the NEW PIM NAK msg downstream. best regards, Liwen-- "R. Venkateswaran" wrote: > Hi Liwen, > > > What I am proposing is that: > > > > 1) the receiver or a router (e.g border router) specify the whole reverse path > > along with the contraints(similar to the ones listed in Daniel O. Awduche's > > document) to RP and send the list along with the PIM JOIN msg towards RP. > > > > 2) the PIM-SM routers along this reverse path join the upstream according to > > the list > > specified in the PIM JOIN msg. > > > > I see some serious problems with this approach. The main concern is > that the resulting "multicast tree" may no longer be a "tree" by > graph-theory definitions. That is, an intermediate router will receive > the same multicast data on more than one incoming link and will have > to forward them multiple times to different receivers because each > receiver wants a certain path for their data. Eventually, you may end > up with a bunch of unicast paths to the receivers, as opposed to a > multicast tree. > > To eliminate these "loops" in the multicast tree, some node > has to remember the entire multicast tree structure and eliminate > duplicate paths at the time of PIM JOIN. I would assume it would be > the RP that has to maintain this information. For large networks, > this will involve too much of state information for the RP to > maintain. > > Regards, > venki > > Disclaimer: The above comments are personal views, and may not > necessarily reflect those of my organization. > -- > R. Venkateswaran (Venki) [email -> mailto:venki@lucent.com ] > [Lucent Technologies Bell Labs (IHP), Room 2E-241,Ph # (630)-979-6253] --------------CAEF4BCEEDFF5B2458ED4733 Content-Type: text/x-vcard; charset=us-ascii; name="liwen.wu.vcf" Content-Description: Card for Liwen Wu Content-Disposition: attachment; filename="liwen.wu.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Wu;Liwen tel;fax:703-724-2003 tel;work:703-724-2619 x-mozilla-html:FALSE org:Alcatel;R&D version:2.1 email;internet:liwen.wu@adn.alcatel.com adr;quoted-printable:;;44983 Knoll Square=0D=0A;Ashburn;VA;20147;U.S.A x-mozilla-cpt:;18304 fn:Liwen Wu end:vcard --------------CAEF4BCEEDFF5B2458ED4733-- From owner-pim@catarina.usc.edu Tue May 25 18:25:42 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00869 for ; Tue, 25 May 1999 18:25:42 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA22780 for pim-list; Tue, 25 May 1999 12:16:01 -0700 Received: from auemlsrv.firewall.lucent.com ([192.11.223.161]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA22776 for ; Tue, 25 May 1999 12:15:56 -0700 Received: from ihgp3.ih.lucent.com (h135-1-27-103.lucent.com [135.1.27.103]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA13763 for ; Tue, 25 May 1999 15:15:55 -0400 (EDT) Received: by ihgp3.ih.lucent.com (8.8.8+Sun/EMS-1.4 sol2) id OAA09321; Tue, 25 May 1999 14:15:44 -0500 (CDT) Cc: pim@catarina.usc.edu, idmr@cs.ucl.ac.uk Received: from il0015venki1.ih.lucent.com by ihgp3.ih.lucent.com (8.8.8+Sun/EMS-1.4 sol2) id OAA09241; Tue, 25 May 1999 14:15:36 -0500 (CDT) Date: Tue, 25 May 1999 14:15:49 -0500 (Central Daylight Time) From: "R. Venkateswaran" Reply-To: "r. venkateswaran" To: Joel Halpern Original-cc: pim@catarina.usc.edu, idmr@cs.ucl.ac.uk Subject: RE: Traffic Engineering for multicast traffic In-Reply-To: Message-ID: X-X-Sender: venki@ihgp3.ih.lucent.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk On Tue, 25 May 1999, Joel Halpern wrote: > There are some problems with this, and probably some better refinements. > > But the fundemental observation is that there is no reason to have the > multicast packets take two paths from the root to another spot on the > tree. Some one path will suffice. Picking which one may be harder than > just "accepting the first". > Yes, the problem here is that each node now has to remember the explicit path from itself to the root. Otherwise, it cannot decide whether a new requested explicit path (in a new PIM JOIN message) to the root is "better" or "worse" than the existing path. Further, if the node decides that the new explicit pathi is "better", it has to then convey this information to all the downstream routers on the multicast tree, because each node now has to update its explicit path to the root. Regards, venki Disclaimer: The above comments are personal views, and may not necessarily reflect those of my organization. -- R. Venkateswaran (Venki) [email -> mailto:venki@lucent.com ] [Lucent Technologies Bell Labs (IHP), Room 2E-241,Ph # (630)-979-6253] From owner-pim@catarina.usc.edu Tue May 25 18:28:42 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00889 for ; Tue, 25 May 1999 18:28:42 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA22571 for pim-list; Tue, 25 May 1999 11:37:58 -0700 Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA22566 for ; Tue, 25 May 1999 11:37:38 -0700 Received: from ihgp3.ih.lucent.com (h135-1-27-103.lucent.com [135.1.27.103]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA21835 for ; Tue, 25 May 1999 14:37:30 -0400 (EDT) Received: by ihgp3.ih.lucent.com (8.8.8+Sun/EMS-1.4 sol2) id NAA27002; Tue, 25 May 1999 13:37:16 -0500 (CDT) Cc: Bora Akyol , mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk, rsvp@isi.edu Received: from il0015venki1.ih.lucent.com by ihgp3.ih.lucent.com (8.8.8+Sun/EMS-1.4 sol2) id NAA26717; Tue, 25 May 1999 13:36:56 -0500 (CDT) Date: Tue, 25 May 1999 13:37:09 -0500 (Central Daylight Time) From: "R. Venkateswaran" Reply-To: "r. venkateswaran" To: Liwen Wu Original-cc: Bora Akyol , mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk, rsvp@isi.edu Subject: Re: Traffic Engineering for multicast traffic In-Reply-To: <374AE75C.B698F2F0@adn.alcatel.com> Message-ID: X-X-Sender: venki@ihgp3.ih.lucent.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi Liwen, > What I am proposing is that: > > 1) the receiver or a router (e.g border router) specify the whole reverse path > along with the contraints(similar to the ones listed in Daniel O. Awduche's > document) to RP and send the list along with the PIM JOIN msg towards RP. > > 2) the PIM-SM routers along this reverse path join the upstream according to > the list > specified in the PIM JOIN msg. > I see some serious problems with this approach. The main concern is that the resulting "multicast tree" may no longer be a "tree" by graph-theory definitions. That is, an intermediate router will receive the same multicast data on more than one incoming link and will have to forward them multiple times to different receivers because each receiver wants a certain path for their data. Eventually, you may end up with a bunch of unicast paths to the receivers, as opposed to a multicast tree. To eliminate these "loops" in the multicast tree, some node has to remember the entire multicast tree structure and eliminate duplicate paths at the time of PIM JOIN. I would assume it would be the RP that has to maintain this information. For large networks, this will involve too much of state information for the RP to maintain. Regards, venki Disclaimer: The above comments are personal views, and may not necessarily reflect those of my organization. -- R. Venkateswaran (Venki) [email -> mailto:venki@lucent.com ] [Lucent Technologies Bell Labs (IHP), Room 2E-241,Ph # (630)-979-6253] From owner-pim@catarina.usc.edu Tue May 25 18:35:56 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00991 for ; Tue, 25 May 1999 18:35:55 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA22638 for pim-list; Tue, 25 May 1999 11:48:17 -0700 Received: from newshub1-work.home.com (newshub1-work.home.com [24.0.0.24]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA22634 for ; Tue, 25 May 1999 11:48:05 -0700 Received: from omniplex.mcquillan.com ([209.125.158.40]) by newshub1-work.home.com (8.8.5/8.8.5-AtHome) with ESMTP id LAA27363 for ; Tue, 25 May 1999 11:47:39 -0700 (PDT) Received: by OMNIPLEX with Internet Mail Service (5.0.1457.3) id ; Tue, 25 May 1999 14:48:13 -0400 Message-ID: From: Joel Halpern To: "r. venkateswaran" Cc: pim@catarina.usc.edu, idmr@cs.ucl.ac.uk Subject: RE: Traffic Engineering for multicast traffic Date: Tue, 25 May 1999 14:48:11 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BEA6BD.9D54E950" Sender: owner-pim@catarina.usc.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_001_01BEA6BD.9D54E950 Content-Type: text/plain Actually, depending upon the "meaning" of the explicit route, there is no need for the RP to keep all the state. For example, one mechanism would be to allow the path to be overridden once you arrived at the tree. That is, once the join reaches an on-tree router, there is no poin in creating a second path from there to the root. So simply stop. A variation on this technique was used with PNNI support for ATM Leaf Initiated Joins for pt-to-multipoint. There are some problems with this, and probably some better refinements. But the fundemental observation is that there is no reason to have the multicast packets take two paths from the root to another spot on the tree. Some one path will suffice. Picking which one may be harder than just "accepting the first". Yours, Joel M. Halpern -----Editted Original Message----- R. Venkateswaran [mailto:venki@lucent.com] wrote: I see some serious problems with this approach. The main concern is that the resulting "multicast tree" may no longer be a "tree" by graph-theory definitions. That is, an intermediate router will receive the same multicast data on more than one incoming link and will have to forward them multiple times to different receivers because each receiver wants a certain path for their data. Eventually, you may end up with a bunch of unicast paths to the receivers, as opposed to a multicast tree. To eliminate these "loops" in the multicast tree, some node has to remember the entire multicast tree structure and eliminate duplicate paths at the time of PIM JOIN. I would assume it would be the RP that has to maintain this information. For large networks, this will involve too much of state information for the RP to maintain. ------ =_NextPart_001_01BEA6BD.9D54E950 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Actually, depending upon the "meaning" of = the explicit route, there is no need for the RP to keep all the = state.

For example, one mechanism would be to allow the = path to be overridden once you arrived at the tree.  That is, once = the join reaches an on-tree router, there is no poin in creating a = second path from there to the root.  So simply stop.  A = variation on this technique was used with PNNI support for ATM Leaf = Initiated Joins for pt-to-multipoint.

There are some problems with this, and probably some = better refinements.
But the fundemental observation is that there is no = reason to have the multicast packets take two paths from the root to = another spot on the tree.  Some one path will suffice.  = Picking which one may be harder than just "accepting the = first".


Yours,
Joel M. Halpern

-----Editted Original Message-----
R. Venkateswaran [mailto:venki@lucent.com] wrote:

I see some serious problems with this approach. The = main concern is
that the resulting "multicast tree" may no = longer be a "tree" by
graph-theory definitions. That is, an intermediate = router will receive
the same multicast data on more than one incoming = link and will have
to forward them multiple times to different = receivers because each
receiver wants a certain path for their data. = Eventually, you may end
up with a bunch of unicast paths to the receivers, = as opposed to a
multicast tree.

To eliminate these "loops" in the = multicast tree, some node
has to remember the entire multicast tree structure = and eliminate
duplicate paths at the time of PIM JOIN. I would = assume it would be
the RP that has to maintain this information.  = For large networks,
this will involve too much of state information for = the RP to
maintain.

------ =_NextPart_001_01BEA6BD.9D54E950-- From owner-pim@catarina.usc.edu Wed May 26 02:38:28 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19042 for ; Wed, 26 May 1999 02:38:27 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id XAA24778 for pim-list; Tue, 25 May 1999 23:28:19 -0700 Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id XAA24774 for ; Tue, 25 May 1999 23:28:14 -0700 Received: (dino@localhost) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id XAA05580; Tue, 25 May 1999 23:27:02 -0700 (PDT) Date: Tue, 25 May 1999 23:27:02 -0700 (PDT) Message-Id: <199905260627.XAA05580@flipper.cisco.com> From: Dino Farinacci To: liwen.wu@adn.alcatel.com CC: mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk, rsvp@isi.edu, liwen.wu@adn.alcatel.com In-reply-to: <374A9D15.BC6524D2@adn.alcatel.com> (message from Liwen Wu on Tue, 25 May 1999 08:52:37 -0400) Subject: Re: Traffic Engineering for multicast traffic Sender: owner-pim@catarina.usc.edu Precedence: bulk >> If these ideas are acceptable, I would like to expand them to >> a internet draft. Liwen, wouldn't it be simpler to allocate a different RP for each group address (or group range) and engineer your network to have RPs along different paths? That assumes shared trees. Using source-trees you could have the source send from different addresses which map to different prefixes which are reachable via different paths. We have customers that do this today. Dino From owner-pim@catarina.usc.edu Wed May 26 03:31:40 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA19324 for ; Wed, 26 May 1999 03:31:39 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id AAA24892 for pim-list; Wed, 26 May 1999 00:24:02 -0700 Received: from iabgfw.iabg.de (firewall-user@iabgfw.iabg.de [194.139.245.2]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id AAA24879 for ; Wed, 26 May 1999 00:23:48 -0700 Received: by iabgfw.iabg.de; id JAA19008; Wed, 26 May 1999 09:24:16 +0200 Received: from iabgmh.iabg.de(10.255.255.2) by iabgfw.iabg.de via smap (4.1) id xma018913; Wed, 26 May 99 09:23:35 +0200 Received: from iabgvw.iabg.de ([10.255.255.8]) by iabgmh.iabg.de (Post.Office MTA v3.5.1 release 219 ID# 127-59214U1600L300S0V35) with ESMTP id de for ; Wed, 26 May 1999 09:23:03 +0200 Received: from iabgdns. (localhost [127.0.0.1]) by iabgvw.iabg.de (8.8.8+Sun/8.8.8) with SMTP id JAA21299 for ; Wed, 26 May 1999 09:23:02 +0200 (MET DST) Received: from iabg.de by iabgdns. (SMI-8.6/SMI-SVR4) id JAA06949; Wed, 26 May 1999 09:23:02 +0200 Message-ID: <374BA156.DE40AD6A@iabg.de> Date: Wed, 26 May 1999 09:23:02 +0200 From: Gerhard Gessler Organization: IABG mbH X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: PIM Mailing List Subject: Re: Pim-dm assert.. References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit Sanjay Wadhwa wrote: > > Hi > I have a question on pim-dm assert mechanism. > Consider the following scenario : > > S > > | | > A-L A-W > | | > ------------------------------- > | > D > > Lets say the assert-winner gets established at time t. > The assert-loser will prune the interface to the lan till time t+210. > Now if at time t+1 assert-winner loses route to the source. > The downstream router potentially may not get any data till t+209. Thats right. > > Does it make sense for the assert-winner in case it's route to source is > lost, > to trigger an Assert with metric infinity, on (non-pruned) OIFs > in all (S,G) entries for this source. The assert loser will receive an > Assert on the > pruned interface, and since it's metric is better, can respond with an > Assert, > and remove prune state on that interface. The assert looser will not respond to this Assert Msg, because it arrives at a pruned interface. This is not in the spec but you can find some statements about this in the mailing list archive (e.g. "Assert on outgoing interface" Mon, 09 Nov 98 19:27:00 PST from vishwas) Hope this helps, Gerhard -- --------------------------------------------------- Gerhard Geßler IABG mbH, Abteilung CS31 Einsteinstr. 20 85521 Ottobrunn Tel. (089) 6088 3954 Fax: (089) 6088 2845 E-Mail: gessler@iabg.de From owner-pim@catarina.usc.edu Wed May 26 03:43:29 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA19389 for ; Wed, 26 May 1999 03:43:28 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id AAA24877 for pim-list; Wed, 26 May 1999 00:23:34 -0700 Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id AAA24873 for ; Wed, 26 May 1999 00:23:26 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 26 May 1999 08:23:10 +0100 To: Dino Farinacci cc: liwen.wu@adn.alcatel.com, mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk, rsvp@isi.edu Subject: Re: Traffic Engineering for multicast traffic In-reply-to: Your message of "Tue, 25 May 1999 23:27:02 PDT." <199905260627.XAA05580@flipper.cisco.com> Date: Wed, 26 May 1999 08:23:08 +0100 Message-ID: <646.927703388@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-pim@catarina.usc.edu Precedence: bulk In message <199905260627.XAA05580@flipper.cisco.com>, Dino Farinacci typed: >>>> If these ideas are acceptable, I would like to expand them to >>>> a internet draft. >> Liwen, wouldn't it be simpler to allocate a different RP for each group >> address (or group range) and engineer your network to have RPs along >> different paths? >> That assumes shared trees. Using source-trees you could have the source >> send from different addresses which map to different prefixes which >> are reachable via different paths. >> We have customers that do this today. right and if you had Hierarchical PIM (the type we proposed) yo ucould have multiple RPs at various "levels" and control the tree structure at quite a fine grain in different regions... (see ftp://cs.ucl.ac.uk/darpa/hpim.ps.gz) all: can we stop CC:ing all the lists - if this is a PIM proposal, it shoudl stay on the PIM WG list only imho.... cheers jon ...but with SM..... From owner-pim@catarina.usc.edu Wed May 26 03:47:02 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA19406 for ; Wed, 26 May 1999 03:47:02 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id AAA24943 for pim-list; Wed, 26 May 1999 00:27:32 -0700 Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id AAA24939 for ; Wed, 26 May 1999 00:27:21 -0700 Received: (dino@localhost) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id AAA08147; Wed, 26 May 1999 00:26:17 -0700 (PDT) Date: Wed, 26 May 1999 00:26:17 -0700 (PDT) Message-Id: <199905260726.AAA08147@flipper.cisco.com> From: Dino Farinacci To: J.Crowcroft@cs.ucl.ac.uk CC: liwen.wu@adn.alcatel.com, mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk, rsvp@isi.edu In-reply-to: <646.927703388@cs.ucl.ac.uk> (message from Jon Crowcroft on Wed, 26 May 1999 08:23:08 +0100) Subject: Re: Traffic Engineering for multicast traffic Sender: owner-pim@catarina.usc.edu Precedence: bulk >> and if you had Hierarchical PIM (the type we proposed) yo ucould have >> multiple RPs at various "levels" and control the tree structure at >> quite a fine grain in different regions... >> (see ftp://cs.ucl.ac.uk/darpa/hpim.ps.gz) The problems with HPIM (which I explained recently to Mark H) in context of unidirectional PIM is that you would have to chain Register messages all the way up the hierarchy and then if you wanted to take downstream shortcuts while the packet was traveling upstream, you'd have to prevent the packet from coming back down from the highest level RP (and causing duplicates to receivers). Dino From owner-pim@catarina.usc.edu Wed May 26 05:51:48 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20058 for ; Wed, 26 May 1999 05:51:47 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id CAA25359 for pim-list; Wed, 26 May 1999 02:43:50 -0700 Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id CAA25355 for ; Wed, 26 May 1999 02:43:41 -0700 Received: from rc.bel.alcatel.be (btmq9s.rc.bel.alcatel.be [138.203.65.182]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id LAA25836; Wed, 26 May 1999 11:42:09 +0200 (MET DST) Received: from alcatel.be by rc.bel.alcatel.be id LAA16949; Wed, 26 May 1999 11:43:24 +0200 (MET DST) Message-ID: <374BC1E4.F246C0A7@alcatel.be> Date: Wed, 26 May 1999 11:41:56 +0200 From: Dirk Ooms X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Liwen Wu CC: mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk, rsvp@isi.edu Subject: Re: Traffic Engineering for multicast traffic References: <374A9D15.BC6524D2@adn.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit I am wondering whether we need a special traffic engineering method for multicast. Is it necessary to make a distinction between unicast and multicast traffic? Section 7 of http://search.ietf.org/internet-drafts/draft-ooms-mpls-multicast-02.txt explains what explicit routing could mean in a multicast context. Either it is overriding the shortest path tree by another explicit tree (as proposed by Liwen) OR the multicast protocols are using the explicit unicast routes to construct the multicast trees. Since traffic engineering does not necessarily need explicit routes (cfr. OMP), I see 2 methods of doing traffic engineering for multicast traffic, without having a dedicated 'multicast traffic engineering method'. In both methods multicast trees are constructed on top of influenced unicast routes. The influencing of the unicast route can be obtained in following two ways: 1)having explicit unicast routes. With the limitation that the explicit unicast routes need to be bidirectional. 2)use OMP. Normally in OMP a node starts load balancing when a downstream link is congested. The only extension needed for multicast is that the join messages are load balanced when an upstream link is congested. These mechanisms are completely independent of the multicast protocol, but not independent of the multicast traffic... and traffic engineering is the thing we want. Dirk -- Dirk Ooms (DN9) Alcatel Research mailto:Dirk.Ooms@alcatel.be Francis Wellesplein 1 Phone: +32 3 240 4732 B-2018 Antwerp Fax: +32 3 240 9932 Belgium From owner-pim@catarina.usc.edu Wed May 26 08:29:17 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22400 for ; Wed, 26 May 1999 08:29:17 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id FAA25858 for pim-list; Wed, 26 May 1999 05:11:31 -0700 Received: from prima.time.saic.com (time.saic.com [205.153.241.31]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id FAA25854 for ; Wed, 26 May 1999 05:11:23 -0700 Received: from degas.time.saic.com (degas.time.saic.com [205.153.241.32]) by prima.time.saic.com (8.9.3/8.8.5) with ESMTP id IAA09321; Wed, 26 May 1999 08:13:46 -0400 (EDT) Message-Id: <199905261213.IAA09321@prima.time.saic.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Dino Farinacci cc: pim@catarina.usc.edu Subject: Re: Traffic Engineering for multicast traffic In-Reply-To: Your message of "Wed, 26 May 1999 00:26:17 PDT." <199905260726.AAA08147@flipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 May 1999 08:11:19 -0400 From: Ken Carlberg Sender: owner-pim@catarina.usc.edu Precedence: bulk Dino, The problems with HPIM (which I explained recently to Mark H) in context of unidirectional PIM is that you would have to chain Register messages all the way up the hierarchy and then if you wanted to take downstream shortcuts while the packet was traveling upstream, you'd have to prevent the packet from coming back down from the highest level RP (and causing duplicates to receivers). does the problem go away with your recent proposal for bi-directional PIM? -ken From owner-pim@catarina.usc.edu Wed May 26 08:32:19 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22528 for ; Wed, 26 May 1999 08:32:19 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id FAA25891 for pim-list; Wed, 26 May 1999 05:23:58 -0700 Received: from adn.alcatel.com (postman.adn.alcatel.com [198.205.32.33]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id FAA25887 for ; Wed, 26 May 1999 05:23:49 -0700 Received: from postal.adn.alcatel.com (postal [198.205.32.56]) by adn.alcatel.com with ESMTP (8.7.6/8.7.1) id IAA24206 for ; Wed, 26 May 1999 08:18:21 -0400 (EDT) Received: from adn.alcatel.com ([198.205.54.160]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA5F64; Wed, 26 May 1999 08:24:26 -0400 Message-ID: <374BE7D8.F33BABB8@adn.alcatel.com> Date: Wed, 26 May 1999 08:23:53 -0400 From: Liwen Wu Organization: Alcatel X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Dino Farinacci CC: mpls@UU.NET, pim@catarina.usc.edu Subject: Re: Traffic Engineering for multicast traffic References: <199905260627.XAA05580@flipper.cisco.com> Content-Type: multipart/mixed; boundary="------------D2F41E7130B4AA3C5E791E44" Sender: owner-pim@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. --------------D2F41E7130B4AA3C5E791E44 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dino Farinacci wrote: > >> If these ideas are acceptable, I would like to expand them to > >> a internet draft. > > Liwen, wouldn't it be simpler to allocate a different RP for each group > address (or group range) and engineer your network to have RPs along > different paths? > > That assumes shared trees. Using source-trees you could have the source > send from different addresses which map to different prefixes which > are reachable via different paths. Hello Dino, Having different RP definitely helps to have different trees not overlapping. But the tree is still built hop-by-hop from leaf to the root, with each individual on-tree node choose its parent independently. What I am try to propose is to have ONLY the leaf choose the whole reverse path from the leaf all the way to root. All the other on-tree nodes just follow the reverse path that leaf has choosen. This idea is very similar to the source routing concept in unicast routing, where the first router choose the the whole path. I can see at least a couple of benefits with this: 1) Only the leaf nodes is making the selection of the reverse path. It is easier especially if QoS/COS gets involved. For example, in a network, some nodes are running with release 1 code, and some nodes are running with release 2 code. There maybe a very minor difference in reverseQOS path selection logic, letting each on-tree node choose its parent independently might be harder than only letting the leaf making the decision. 2) Very similar to unicast traffic engineering, the leaf node can prune all the congested links and nodes out before doing the calculation. 3) Also, if you want to build a colored tree, the leaf can calculate the reverse colord path use only the same color links and same color nodes. best regards, Liwen-- > > > We have customers that do this today. > > Dino --------------D2F41E7130B4AA3C5E791E44 Content-Type: text/x-vcard; charset=us-ascii; name="liwen.wu.vcf" Content-Description: Card for Liwen Wu Content-Disposition: attachment; filename="liwen.wu.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Wu;Liwen tel;fax:703-724-2003 tel;work:703-724-2619 x-mozilla-html:FALSE org:Alcatel;R&D version:2.1 email;internet:liwen.wu@adn.alcatel.com adr;quoted-printable:;;44983 Knoll Square=0D=0A;Ashburn;VA;20147;U.S.A x-mozilla-cpt:;18304 fn:Liwen Wu end:vcard --------------D2F41E7130B4AA3C5E791E44-- From owner-pim@catarina.usc.edu Wed May 26 08:41:52 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22725 for ; Wed, 26 May 1999 08:41:51 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id FAA25934 for pim-list; Wed, 26 May 1999 05:35:04 -0700 Received: from adn.alcatel.com (postman.adn.alcatel.com [198.205.32.33]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id FAA25930 for ; Wed, 26 May 1999 05:34:56 -0700 Received: from postal.adn.alcatel.com (postal [198.205.32.56]) by adn.alcatel.com with ESMTP (8.7.6/8.7.1) id IAA24861 for ; Wed, 26 May 1999 08:29:29 -0400 (EDT) Received: from adn.alcatel.com ([198.205.54.160]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA610E; Wed, 26 May 1999 08:35:34 -0400 Message-ID: <374BEA75.4D7C67ED@adn.alcatel.com> Date: Wed, 26 May 1999 08:35:01 -0400 From: Liwen Wu Organization: Alcatel X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "r. venkateswaran" CC: Joel Halpern , pim@catarina.usc.edu Subject: Re: Traffic Engineering for multicast traffic References: Content-Type: multipart/mixed; boundary="------------9173FAB8F394CB246B746D54" Sender: owner-pim@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. --------------9173FAB8F394CB246B746D54 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "R. Venkateswaran" wrote: > On Tue, 25 May 1999, Joel Halpern wrote: > > > There are some problems with this, and probably some better refinements. > > > > But the fundemental observation is that there is no reason to have the > > multicast packets take two paths from the root to another spot on the > > tree. Some one path will suffice. Picking which one may be harder than > > just "accepting the first". > > > > Yes, the problem here is that each node now has to remember the > explicit path from itself to the root. Otherwise, it cannot decide > whether a new requested explicit path (in a new PIM JOIN message) to > the root is "better" or "worse" than the existing path. Yes, each on-tree nodes remember ONLY 1 explicit path from itself to the root. > > > Further, if the node decides that the new explicit pathi is "better", > it has to then convey this information to all the downstream routers > on the multicast tree, because each node now has to update its > explicit path to the root. Yes, a new PIM JOIN-ACK msg(very similar to RSVP PATH msg) can be defined to flow from the root to all the downstream routers. > > > Regards, > venki > > Disclaimer: The above comments are personal views, and may not > necessarily reflect those of my organization. > -- > R. Venkateswaran (Venki) [email -> mailto:venki@lucent.com ] > [Lucent Technologies Bell Labs (IHP), Room 2E-241,Ph # (630)-979-6253] --------------9173FAB8F394CB246B746D54 Content-Type: text/x-vcard; charset=us-ascii; name="liwen.wu.vcf" Content-Description: Card for Liwen Wu Content-Disposition: attachment; filename="liwen.wu.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Wu;Liwen tel;fax:703-724-2003 tel;work:703-724-2619 x-mozilla-html:FALSE org:Alcatel;R&D version:2.1 email;internet:liwen.wu@adn.alcatel.com adr;quoted-printable:;;44983 Knoll Square=0D=0A;Ashburn;VA;20147;U.S.A x-mozilla-cpt:;18304 fn:Liwen Wu end:vcard --------------9173FAB8F394CB246B746D54-- From owner-pim@catarina.usc.edu Wed May 26 09:24:23 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24070 for ; Wed, 26 May 1999 09:24:23 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id GAA26131 for pim-list; Wed, 26 May 1999 06:18:47 -0700 Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id GAA26127 for ; Wed, 26 May 1999 06:18:43 -0700 Received: by NTSERVER1 with Internet Mail Service (5.0.1460.8) id ; Wed, 26 May 1999 09:18:14 -0400 Message-ID: From: Sanjay Wadhwa To: Gerhard Gessler , PIM Mailing List Subject: RE: Pim-dm assert.. Date: Wed, 26 May 1999 09:18:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA24070 The intent there was that the assert-loser should not respond with another assert when the assert-winner does an assert after winning, since that is useless. However, I am proposing that on the pruned interface assert should be replied to ONLY if you have a better metric than what you receive in the assert. Thanks Sanjay > -----Original Message----- > From: Gerhard Gessler [mailto:gessler@iabg.de] > Sent: Wednesday, May 26, 1999 3:23 AM > To: PIM Mailing List > Subject: Re: Pim-dm assert.. > > > Sanjay Wadhwa wrote: > > > > Hi > > I have a question on pim-dm assert mechanism. > > Consider the following scenario : > > > > S > > > > | | > > A-L A-W > > | | > > ------------------------------- > > | > > D > > > > Lets say the assert-winner gets established at time t. > > The assert-loser will prune the interface to the lan till > time t+210. > > Now if at time t+1 assert-winner loses route to the source. > > The downstream router potentially may not get any data till t+209. > > Thats right. > > > > > Does it make sense for the assert-winner in case it's route > to source is > > lost, > > to trigger an Assert with metric infinity, on (non-pruned) OIFs > > in all (S,G) entries for this source. The assert loser will > receive an > > Assert on the > > pruned interface, and since it's metric is better, can > respond with an > > Assert, > > and remove prune state on that interface. > > The assert looser will not respond to this Assert Msg, because it > arrives at a pruned interface. This is not in the spec but > you can find > some statements about this in the mailing list archive (e.g. > "Assert on > outgoing interface" Mon, 09 Nov 98 19:27:00 PST from vishwas) > > Hope this helps, > > Gerhard > > -- > --------------------------------------------------- > Gerhard Geßler > > IABG mbH, Abteilung CS31 > Einsteinstr. 20 > 85521 Ottobrunn > > Tel. (089) 6088 3954 > Fax: (089) 6088 2845 > > E-Mail: gessler@iabg.de > From owner-pim@catarina.usc.edu Wed May 26 13:05:01 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00636 for ; Wed, 26 May 1999 13:05:00 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id JAA26834 for pim-list; Wed, 26 May 1999 09:57:36 -0700 Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id JAA26830 for ; Wed, 26 May 1999 09:57:32 -0700 Received: (dino@localhost) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id JAA01457; Wed, 26 May 1999 09:56:29 -0700 (PDT) Date: Wed, 26 May 1999 09:56:29 -0700 (PDT) Message-Id: <199905261656.JAA01457@flipper.cisco.com> From: Dino Farinacci To: carlberg@time.saic.com CC: pim@catarina.usc.edu In-reply-to: <199905261213.IAA09321@prima.time.saic.com> (message from Ken Carlberg on Wed, 26 May 1999 08:11:19 -0400) Subject: Re: Traffic Engineering for multicast traffic Sender: owner-pim@catarina.usc.edu Precedence: bulk >> does the problem go away with your recent proposal for bi-directional PIM? I think so as long as you put more encoding semantics in the UMP option. Dino From owner-pim@catarina.usc.edu Wed May 26 15:34:56 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03183 for ; Wed, 26 May 1999 15:34:56 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA00383 for pim-list; Wed, 26 May 1999 12:13:09 -0700 Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA00379 for ; Wed, 26 May 1999 12:13:01 -0700 Received: by NTSERVER1 with Internet Mail Service (5.0.1460.8) id ; Wed, 26 May 1999 15:12:37 -0400 Message-ID: From: Sanjay Wadhwa To: Desikan Saravanan , Sanjay Wadhwa , Gerhard Gessler , PIM Mailing List Subject: RE: Assert mechanism Date: Wed, 26 May 1999 15:12:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk I think it is ok to wait till 210 secs (or maybe less) and not re-assert if metric at the winner or loser changes. There is no data loss there.. But in case of a loss of route to the source it seems like a resonable optimization to re-assert on all non-pruned OIFs in all (S,G) entries for that source. And since this is done for only non-pruned OIFs, loss of route to source will trigger an assert only at the current assert-winner. Thanks Sanjay > -----Original Message----- > From: Desikan Saravanan [mailto:dsaravanan@extremenetworks.com] > Sent: Wednesday, May 26, 1999 2:40 PM > To: 'Sanjay Wadhwa'; Gerhard Gessler; PIM Mailing List > Subject: FW: Assert mechanism > > > Sanjay, > > Sometime back, I also proposed the very same idea. > Here is Ahmed's reply to that. > > It is still not convincing to me. > > What we can do is. > > Whenever the route changes, all the affected forwarding > entries's assert > state shall be cleared. > So this would allow again asserting by both the previuos > winner and loser > and > they could elect the new one. > > Des > > -----Original Message----- > From: Ahmed A-G Helmy [mailto:ahelmy@catarina.usc.edu] > Sent: Tuesday, September 01, 1998 2:26 AM > To: Desikan Saravanan > Cc: 'pim_ml' > Subject: Re: Assert mechanism > > > > Hi > > > > I have got a doubt in how assert mechanism works. > > Say Router A and B are upstream routers and C is downstream. > > And during the assert process, router A wins. > > > > say after some time, router A looses the route to the > source concerned. > > what happens after that? > > > > The downstream router would set a timer after which it would > consult with > its unicast routing tables, and if the routes have changed > such that B is > the new favored upstream router, a join would be sent to B. > > The problem with your suggestion is that A's metric may stay > the same, > while B's metric may become less (i.e. becomes more > favorable), and this > condition is not dealt with below, > > Regards, > -A > > > what it should do is: router B should become the forwarder > in the LAN. > > but how router B knows that it should do that? > > > > I propose: > > "When the Assert winner changes/looses the unicast route to > the source, > > it should send an assert packet in the LAN with the new > metric. If it > > looses > > the route, the metric should be 0xfffffff and preference should be > > 0x7fffffff" > > > > This would immediately trigger another assert election and > the router > > deserved > > to be the winner, would win and start forwarding the multicast data > > properly. > > > > Am I right? > > > > Rgds > > Desikan > > > From owner-pim@catarina.usc.edu Wed May 26 16:03:37 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03911 for ; Wed, 26 May 1999 16:03:36 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA00724 for pim-list; Wed, 26 May 1999 12:50:12 -0700 Received: from sol.extremenetworks.com ([216.52.8.2]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA27186 for ; Wed, 26 May 1999 11:40:31 -0700 Received: by ftp.extremenetworks.com with Internet Mail Service (5.5.2448.0) id ; Wed, 26 May 1999 11:39:58 -0700 Message-ID: From: Desikan Saravanan To: "'Sanjay Wadhwa'" , Gerhard Gessler , PIM Mailing List Subject: FW: Assert mechanism Date: Wed, 26 May 1999 11:39:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk Sanjay, Sometime back, I also proposed the very same idea. Here is Ahmed's reply to that. It is still not convincing to me. What we can do is. Whenever the route changes, all the affected forwarding entries's assert state shall be cleared. So this would allow again asserting by both the previuos winner and loser and they could elect the new one. Des -----Original Message----- From: Ahmed A-G Helmy [mailto:ahelmy@catarina.usc.edu] Sent: Tuesday, September 01, 1998 2:26 AM To: Desikan Saravanan Cc: 'pim_ml' Subject: Re: Assert mechanism > Hi > > I have got a doubt in how assert mechanism works. > Say Router A and B are upstream routers and C is downstream. > And during the assert process, router A wins. > > say after some time, router A looses the route to the source concerned. > what happens after that? > The downstream router would set a timer after which it would consult with its unicast routing tables, and if the routes have changed such that B is the new favored upstream router, a join would be sent to B. The problem with your suggestion is that A's metric may stay the same, while B's metric may become less (i.e. becomes more favorable), and this condition is not dealt with below, Regards, -A > what it should do is: router B should become the forwarder in the LAN. > but how router B knows that it should do that? > > I propose: > "When the Assert winner changes/looses the unicast route to the source, > it should send an assert packet in the LAN with the new metric. If it > looses > the route, the metric should be 0xfffffff and preference should be > 0x7fffffff" > > This would immediately trigger another assert election and the router > deserved > to be the winner, would win and start forwarding the multicast data > properly. > > Am I right? > > Rgds > Desikan > From owner-pim@catarina.usc.edu Wed May 26 16:30:23 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04307 for ; Wed, 26 May 1999 16:30:23 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA01064 for pim-list; Wed, 26 May 1999 13:20:39 -0700 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA01060 for ; Wed, 26 May 1999 13:20:34 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 860504CE2E; Wed, 26 May 1999 16:20:34 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id QAA23964; Wed, 26 May 1999 16:20:33 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.7/8.8.5) id QAA11978; Wed, 26 May 1999 16:20:32 -0400 (EDT) Message-Id: <199905262020.QAA11978@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: dsaravanan@extremenetworks.com Subject: Re: FW: Assert mechanism Cc: swadhwa@redstonecom.com, gessler@iabg.de, pim@catarina.usc.edu Date: Wed, 26 May 1999 13:20:32 -0700 Versions: dmail (solaris) 2.2c/makemail 2.8t Sender: owner-pim@catarina.usc.edu Precedence: bulk The loser's route didn't necessarily change, which is what I think Ahmed was saying. Bill From owner-pim@catarina.usc.edu Wed May 26 19:09:38 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05923 for ; Wed, 26 May 1999 19:09:37 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA00201 for pim-list; Wed, 26 May 1999 11:50:02 -0700 Received: from sol.extremenetworks.com ([216.52.8.2]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA27186 for ; Wed, 26 May 1999 11:40:31 -0700 Received: by ftp.extremenetworks.com with Internet Mail Service (5.5.2448.0) id ; Wed, 26 May 1999 11:39:58 -0700 Message-ID: From: Desikan Saravanan To: "'Sanjay Wadhwa'" , Gerhard Gessler , PIM Mailing List Subject: FW: Assert mechanism Date: Wed, 26 May 1999 11:39:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk Sanjay, Sometime back, I also proposed the very same idea. Here is Ahmed's reply to that. It is still not convincing to me. What we can do is. Whenever the route changes, all the affected forwarding entries's assert state shall be cleared. So this would allow again asserting by both the previuos winner and loser and they could elect the new one. Des -----Original Message----- From: Ahmed A-G Helmy [mailto:ahelmy@catarina.usc.edu] Sent: Tuesday, September 01, 1998 2:26 AM To: Desikan Saravanan Cc: 'pim_ml' Subject: Re: Assert mechanism > Hi > > I have got a doubt in how assert mechanism works. > Say Router A and B are upstream routers and C is downstream. > And during the assert process, router A wins. > > say after some time, router A looses the route to the source concerned. > what happens after that? > The downstream router would set a timer after which it would consult with its unicast routing tables, and if the routes have changed such that B is the new favored upstream router, a join would be sent to B. The problem with your suggestion is that A's metric may stay the same, while B's metric may become less (i.e. becomes more favorable), and this condition is not dealt with below, Regards, -A > what it should do is: router B should become the forwarder in the LAN. > but how router B knows that it should do that? > > I propose: > "When the Assert winner changes/looses the unicast route to the source, > it should send an assert packet in the LAN with the new metric. If it > looses > the route, the metric should be 0xfffffff and preference should be > 0x7fffffff" > > This would immediately trigger another assert election and the router > deserved > to be the winner, would win and start forwarding the multicast data > properly. > > Am I right? > > Rgds > Desikan > From owner-pim@catarina.usc.edu Wed May 26 19:37:04 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06183 for ; Wed, 26 May 1999 19:37:03 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA27190 for pim-list; Wed, 26 May 1999 11:40:36 -0700 Received: from sol.extremenetworks.com ([216.52.8.2]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA27186 for ; Wed, 26 May 1999 11:40:31 -0700 Received: by ftp.extremenetworks.com with Internet Mail Service (5.5.2448.0) id ; Wed, 26 May 1999 11:39:58 -0700 Message-ID: From: Desikan Saravanan To: "'Sanjay Wadhwa'" , Gerhard Gessler , PIM Mailing List Subject: FW: Assert mechanism Date: Wed, 26 May 1999 11:39:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk Sanjay, Sometime back, I also proposed the very same idea. Here is Ahmed's reply to that. It is still not convincing to me. What we can do is. Whenever the route changes, all the affected forwarding entries's assert state shall be cleared. So this would allow again asserting by both the previuos winner and loser and they could elect the new one. Des -----Original Message----- From: Ahmed A-G Helmy [mailto:ahelmy@catarina.usc.edu] Sent: Tuesday, September 01, 1998 2:26 AM To: Desikan Saravanan Cc: 'pim_ml' Subject: Re: Assert mechanism > Hi > > I have got a doubt in how assert mechanism works. > Say Router A and B are upstream routers and C is downstream. > And during the assert process, router A wins. > > say after some time, router A looses the route to the source concerned. > what happens after that? > The downstream router would set a timer after which it would consult with its unicast routing tables, and if the routes have changed such that B is the new favored upstream router, a join would be sent to B. The problem with your suggestion is that A's metric may stay the same, while B's metric may become less (i.e. becomes more favorable), and this condition is not dealt with below, Regards, -A > what it should do is: router B should become the forwarder in the LAN. > but how router B knows that it should do that? > > I propose: > "When the Assert winner changes/looses the unicast route to the source, > it should send an assert packet in the LAN with the new metric. If it > looses > the route, the metric should be 0xfffffff and preference should be > 0x7fffffff" > > This would immediately trigger another assert election and the router > deserved > to be the winner, would win and start forwarding the multicast data > properly. > > Am I right? > > Rgds > Desikan > From owner-pim@catarina.usc.edu Wed May 26 19:54:34 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06263 for ; Wed, 26 May 1999 19:54:34 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA26899 for pim-list; Wed, 26 May 1999 10:11:56 -0700 Received: from smtprich.nortel.com ([192.135.215.8]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA26895 for ; Wed, 26 May 1999 10:11:49 -0700 Received: from zcard00n.ca.nortel.com (actually 47.116.0.118) by smtprich.nortel.com; Wed, 26 May 1999 12:11:36 -0500 Received: from zcard008.bnr.ca (zcard008.ca.nortel.com [47.127.82.62]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id LSNZSK44; Wed, 26 May 1999 13:11:36 -0400 Received: from nortel.com (zcars02x.ca.nortel.com [47.23.81.10]) by zcard008.bnr.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id LNKY1J71; Wed, 26 May 1999 13:11:33 -0400 Message-ID: <374C2B45.3D8316AD@nortel.com> Date: Wed, 26 May 1999 13:11:34 -0400 From: "Cheng-Yin Lee" X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: Liwen Wu CC: Dino Farinacci , mpls@UU.NET, pim@catarina.usc.edu, "idmr@cs.ucl.ac.uk" , Dirk Ooms Subject: Re: Traffic Engineering for multicast traffic References: <199905260627.XAA05580@flipper.cisco.com> <374BE7D8.F33BABB8@adn.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Liwen Wu wrote: > Dino Farinacci wrote: > > > >> If these ideas are acceptable, I would like to expand them to > > >> a internet draft. > > > > Liwen, wouldn't it be simpler to allocate a different RP for each group > > address (or group range) and engineer your network to have RPs along > > different paths? The intent is to be able to direct the join towards paths that are statically configured or can be computed (eg using a Constraint Based Routing process as proposed in igp traffic engineering drafts) to satisfy the 'qos' requirement (as Liwen and Dirk have also mentioned, i think). When there are a lot of groups with different 'qos' needs, having the paths towards the root/RP computed will be more manageable. > What I am try to propose is to have ONLY the leaf choose the whole > reverse path from the leaf all the way to root. All the other on-tree nodes > just > follow the reverse path that leaf has choosen. This idea is very similar to > the source routing concept in unicast routing, where the first router choose > the > the whole path. Dirk and I have also been working on directing the join using explicit unicast routes, but not all the way to the root from each leaf (there are pros and cons to this). The approach we have taken is to use MPLS functionalities (label, explicit route object) to do traffic engineering (by directing the joins) and do forwarding only in the multicast routing protocol. That way we don't have to include MPLS functionalities in multicast routing protocols or incorporate multicast routing functionalities in multicast traffic engineering (using MPLS). Perhaps we could merge some of these (and other) ideas? cheers, cyl From owner-pim@catarina.usc.edu Wed May 26 20:29:33 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06460 for ; Wed, 26 May 1999 20:29:32 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA00685 for pim-list; Wed, 26 May 1999 17:24:37 -0700 Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id RAA00681 for ; Wed, 26 May 1999 17:24:33 -0700 Received: (dino@localhost) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id RAA15345; Wed, 26 May 1999 17:24:00 -0700 (PDT) Date: Wed, 26 May 1999 17:24:00 -0700 (PDT) Message-Id: <199905270024.RAA15345@flipper.cisco.com> From: Dino Farinacci To: liwen.wu@adn.alcatel.com CC: mpls@UU.NET, pim@catarina.usc.edu In-reply-to: <374BE7D8.F33BABB8@adn.alcatel.com> (message from Liwen Wu on Wed, 26 May 1999 08:23:53 -0400) Subject: Re: Traffic Engineering for multicast traffic Sender: owner-pim@catarina.usc.edu Precedence: bulk >> What I am try to propose is to have ONLY the leaf choose the whole >> reverse path from the leaf all the way to root. All the other on-tree nodes >> just >> follow the reverse path that leaf has choosen. This idea is very similar to >> the source routing concept in unicast routing, where the first router choose >> the >> the whole path. Why would you want to consider doing it this way. You'd have to invent a new mechanism to find: 1) the root of the tree 2) the path to the root of the tree And if you didn't do this apriori to someone joining the group, you'd have longer join latencies then today's schemes. And to find the path of the tree which has "available" or "non-congested" resources would be inventing some the TR stuff going on in unicast routing. >> 1) Only the leaf nodes is making the selection of the reverse path. It is >> easier especially >> if QoS/COS gets involved. For example, in a network, some nodes are running >> with release 1 code, and some nodes are running with release 2 code. There >> maybe >> a very minor difference in reverseQOS path selection logic, letting each >> on-tree node >> choose its parent independently might be harder than only letting the leaf >> making >> the decision. You want to design a new protocol/mechanism to deal with different software releases. I think there are better/(more local) ways to solve this. Also, doing path selection in one place doesn't make it any simpler. >> 2) Very similar to unicast traffic engineering, the leaf node can prune all the >> congested >> links and nodes out before doing the calculation. You could do this with hop-by-hop state too. >> 3) Also, if you want to build a colored tree, the leaf can calculate the >> reverse colord >> path use only the same color links and same color nodes. A colored tree is just like joining another group. So let's step back and ask what problem you are trying to solve? At first, I thought you wanted to solve the fanout issue at any one node. Meaning, say we have a fanout of 8 interfaces in a Chicago router that could be split to have 4 in a Houston router and 4 in the Chicago router. If this is one of the issues you wanted to address, why would this be a good thing. It sounds like you'd be pushing the fanout higher towards the root. I don't see providers wanting to do that. They don't want to fanout transit traffic, they want fanout to their own customer receivers and push the responsiblity of replication on their peers, if they can. So, I'd like to hear a clear description of the problem you want to solve. Dino From owner-pim@catarina.usc.edu Thu May 27 00:44:03 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09960 for ; Thu, 27 May 1999 00:44:02 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id VAA01656 for pim-list; Wed, 26 May 1999 21:39:06 -0700 Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id VAA01652 for ; Wed, 26 May 1999 21:39:02 -0700 Received: from zcard00n.ca.nortel.com (actually 47.116.0.118) by smtprich.nortel.com; Wed, 26 May 1999 23:38:40 -0500 Received: from zcard008.bnr.ca (zcard008.ca.nortel.com [47.127.82.62]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id LSNZSQQT; Thu, 27 May 1999 00:38:39 -0400 Received: from nortel.com (zmerh02h.ca.nortel.com [47.169.33.100]) by zcard008.bnr.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id LNKY1KZG; Thu, 27 May 1999 00:38:35 -0400 Message-ID: <374CBC94.F70D9A73@nortel.com> Date: Wed, 26 May 1999 23:31:32 -0400 From: "Cheng-Yin Lee" X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dino Farinacci CC: liwen.wu@adn.alcatel.com, mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk Subject: Re: Traffic Engineering for multicast traffic References: <199905270024.RAA15345@flipper.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dino Farinacci wrote: > So let's step back and ask what problem you are trying to solve? ok, let's start with a clean slate. Let's forget about the actual mechanisms used to do traffic engineering (i'm not in favour of putting MPLS functionalities in multicast routing protocols or to have a leaf join all the way to the root for TE purposes, either but we can work out the details later). What we want to provide are tools that ISPs can use to engineer multicast traffic. MPLS and constraint based routing allow us to build those tools. ISPs can then used them to engineer multicast traffic from certain groups to go on certain paths only or to decrease the fanout for eg. All the pieces may not be implemented or specified yet, but i think we have a framework to build these tools. cheers, cyl Dino Farinacci wrote: > > >> What I am try to propose is to have ONLY the leaf choose the whole > >> reverse path from the leaf all the way to root. All the other on-tree nodes > >> just > >> follow the reverse path that leaf has choosen. This idea is very similar to > >> the source routing concept in unicast routing, where the first router choose > >> the > >> the whole path. > > Why would you want to consider doing it this way. You'd have to invent > a new mechanism to find: > > 1) the root of the tree > 2) the path to the root of the tree > > And if you didn't do this apriori to someone joining the group, you'd have > longer join latencies then today's schemes. > > And to find the path of the tree which has "available" or "non-congested" > resources would be inventing some the TR stuff going on in unicast > routing. > > >> 1) Only the leaf nodes is making the selection of the reverse path. It is > >> easier especially > >> if QoS/COS gets involved. For example, in a network, some nodes are running > >> with release 1 code, and some nodes are running with release 2 code. There > >> maybe > >> a very minor difference in reverseQOS path selection logic, letting each > >> on-tree node > >> choose its parent independently might be harder than only letting the leaf > >> making > >> the decision. > > You want to design a new protocol/mechanism to deal with different > software releases. I think there are better/(more local) ways to solve > this. > > Also, doing path selection in one place doesn't make it any simpler. > > >> 2) Very similar to unicast traffic engineering, the leaf node can prune all the > >> congested > >> links and nodes out before doing the calculation. > > You could do this with hop-by-hop state too. > > >> 3) Also, if you want to build a colored tree, the leaf can calculate the > >> reverse colord > >> path use only the same color links and same color nodes. > > A colored tree is just like joining another group. > > So let's step back and ask what problem you are trying to solve? At first, > I thought you wanted to solve the fanout issue at any one node. Meaning, > say we have a fanout of 8 interfaces in a Chicago router that could be > split to have 4 in a Houston router and 4 in the Chicago router. > > If this is one of the issues you wanted to address, why would this be > a good thing. It sounds like you'd be pushing the fanout higher towards > the root. I don't see providers wanting to do that. They don't want to > fanout transit traffic, they want fanout to their own customer receivers > and push the responsiblity of replication on their peers, if they can. > > So, I'd like to hear a clear description of the problem you want to solve. > > Dino > > From owner-pim@catarina.usc.edu Thu May 27 04:48:53 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24023 for ; Thu, 27 May 1999 04:48:52 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id BAA02145 for pim-list; Thu, 27 May 1999 01:34:33 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id BAA02138 for ; Thu, 27 May 1999 01:34:27 -0700 From: Masataka Ohta Message-Id: <199905270817.RAA12019@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA12019; Thu, 27 May 1999 17:16:57 +0859 Subject: Re: Traffic Engineering for multicast traffic To: leecy@nortelnetworks.com (Cheng-Yin Lee) Date: Thu, 27 May 99 17:16:56 JST Cc: dino@cisco.com, liwen.wu@adn.alcatel.com, mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk In-Reply-To: <374CBC94.F70D9A73@nortel.com>; from "Cheng-Yin Lee" at May 26, 99 11:31 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-pim@catarina.usc.edu Precedence: bulk Cheng-Yin; > Dino Farinacci wrote: > > So let's step back and ask what problem you are trying to solve? > > ok, let's start with a clean slate. Let's forget about the actual > mechanisms used to do traffic engineering (i'm not in favour of putting > MPLS functionalities in multicast routing protocols or to have a leaf > join all the way to the root for TE purposes, either but we can work out > the details later). > > What we want to provide are tools that ISPs can use to engineer > multicast traffic. MPLS and constraint based routing allow us to build > those tools. ISPs can then used them to engineer multicast traffic from > certain groups to go on certain paths only or to decrease the fanout for > eg. All the pieces may not be implemented or specified yet, but i think > we have a framework to build these tools. From the fact that multicast route aggregation is impossible, it can directly be derived that MPLS is useless for multicast. You don't even have to consider policy/QoS. However, this is a useless arguement, because MPLS a cousin of ATM and is useless for anything. Masataka Ohta From owner-pim@catarina.usc.edu Thu May 27 08:06:17 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26015 for ; Thu, 27 May 1999 08:06:16 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id FAA02900 for pim-list; Thu, 27 May 1999 05:01:40 -0700 Received: from adn.alcatel.com (postman.adn.alcatel.com [198.205.32.33]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id FAA02896 for ; Thu, 27 May 1999 05:01:35 -0700 Received: from postal.adn.alcatel.com (postal [198.205.32.56]) by adn.alcatel.com with ESMTP (8.7.6/8.7.1) id HAA18634 for ; Thu, 27 May 1999 07:56:08 -0400 (EDT) Received: from adn.alcatel.com ([198.205.54.160]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA1095; Thu, 27 May 1999 08:02:12 -0400 Message-ID: <374D3423.CA5DAC14@adn.alcatel.com> Date: Thu, 27 May 1999 08:01:39 -0400 From: Liwen Wu Organization: Alcatel X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Dino Farinacci CC: mpls@UU.NET, pim@catarina.usc.edu Subject: Re: Traffic Engineering for multicast traffic References: <199905270024.RAA15345@flipper.cisco.com> Content-Type: multipart/mixed; boundary="------------CB5D77BB855F96507BE083B8" Sender: owner-pim@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. --------------CB5D77BB855F96507BE083B8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dino Farinacci wrote: > >> What I am try to propose is to have ONLY the leaf choose the whole > >> reverse path from the leaf all the way to root. All the other on-tree nodes > >> just > >> follow the reverse path that leaf has choosen. This idea is very similar to > >> the source routing concept in unicast routing, where the first router choose > >> the > >> the whole path. > > Why would you want to consider doing it this way. You'd have to invent > a new mechanism to find: > > 1) the root of the tree > 2) the path to the root of the tree No, you can still use the same way that how you choose your RP today. Then the leaf computes the whole reverse path to this root according to its own topology database or by some other mechanism(e.g. "manager" mentioned in QoSMIC, or NMS) > > > And if you didn't do this apriori to someone joining the group, you'd have > longer join latencies then today's schemes. > > And to find the path of the tree which has "available" or "non-congested" > resources would be inventing some the TR stuff going on in unicast > routing. Unicast routing is alway doing this today for unicast traffic engineering. > > > >> 1) Only the leaf nodes is making the selection of the reverse path. It is > >> easier especially > >> if QoS/COS gets involved. For example, in a network, some nodes are running > >> with release 1 code, and some nodes are running with release 2 code. There > >> maybe > >> a very minor difference in reverseQOS path selection logic, letting each > >> on-tree node > >> choose its parent independently might be harder than only letting the leaf > >> making > >> the decision. > > You want to design a new protocol/mechanism to deal with different > software releases. I think there are better/(more local) ways to solve > this. > > Also, doing path selection in one place doesn't make it any simpler. > > >> 2) Very similar to unicast traffic engineering, the leaf node can prune all the > >> congested > >> links and nodes out before doing the calculation. > > You could do this with hop-by-hop state too. Same argument here as why people is doing source routing for unicast traffic in addition to hop-by-hop routing. > > > >> 3) Also, if you want to build a colored tree, the leaf can calculate the > >> reverse colord > >> path use only the same color links and same color nodes. > > A colored tree is just like joining another group. > > So let's step back and ask what problem you are trying to solve? At first, > I thought you wanted to solve the fanout issue at any one node. Meaning, > say we have a fanout of 8 interfaces in a Chicago router that could be > split to have 4 in a Houston router and 4 in the Chicago router. > > If this is one of the issues you wanted to address, why would this be > a good thing. It sounds like you'd be pushing the fanout higher towards > the root. I don't see providers wanting to do that. They don't want to > fanout transit traffic, they want fanout to their own customer receivers > and push the responsiblity of replication on their peers, if they can. Yes, you raised a very good example here. When there are thousands of mulitcast groups in a backbone carrier network, 1) for some groups, you want to push fanout higher, and 2) for some groups you want to push fanout lower, also 3) for some group you want to choose certain fanout point 4) for some group you want to avoid certain fanout point. Also, if some group trees requires certain QoS/COS constraints. I would thought multicast traffic engineering can help to solve these problems. And to support this, PIM-SM seems not that hard with only following extensions: 1) a new PIM-SM msg, JOIN-ACK/JOIN-NAK 2) a new object(fields) in JOIN msg which carry the reverse explicit path and QoS/COS contraints 3) At any on-tree node(merge point, or fanout point), merge these explicit path, and send 1 JOIN with QoS/COS contraint towards the RP best regards, Liwen-- > > > So, I'd like to hear a clear description of the problem you want to solve. > > Dino > > --------------CB5D77BB855F96507BE083B8 Content-Type: text/x-vcard; charset=us-ascii; name="liwen.wu.vcf" Content-Description: Card for Liwen Wu Content-Disposition: attachment; filename="liwen.wu.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Wu;Liwen tel;fax:703-724-2003 tel;work:703-724-2619 x-mozilla-html:FALSE org:Alcatel;R&D version:2.1 email;internet:liwen.wu@adn.alcatel.com adr;quoted-printable:;;44983 Knoll Square=0D=0A;Ashburn;VA;20147;U.S.A x-mozilla-cpt:;18304 fn:Liwen Wu end:vcard --------------CB5D77BB855F96507BE083B8-- From owner-pim@catarina.usc.edu Thu May 27 08:14:57 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26240 for ; Thu, 27 May 1999 08:14:56 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id FAA02970 for pim-list; Thu, 27 May 1999 05:12:46 -0700 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id FAA02966 for ; Thu, 27 May 1999 05:12:42 -0700 Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id FAA22146; Thu, 27 May 1999 05:12:04 -0700 (PDT) Message-Id: <199905271212.FAA22146@omega.cisco.com> To: Cheng-Yin Lee cc: Dino Farinacci , liwen.wu@adn.alcatel.com, mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk Subject: Re: Traffic Engineering for multicast traffic In-reply-to: Your message of "Wed, 26 May 1999 23:31:32 EDT." <374CBC94.F70D9A73@nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22144.927807124.1@cisco.com> Date: Thu, 27 May 1999 05:12:04 -0700 From: Yakov Rekhter Sender: owner-pim@catarina.usc.edu Precedence: bulk > Dino Farinacci wrote: > > So let's step back and ask what problem you are trying to solve? > > ok, let's start with a clean slate. Let's forget about the actual > mechanisms used to do traffic engineering (i'm not in favour of putting > MPLS functionalities in multicast routing protocols or to have a leaf > join all the way to the root for TE purposes, either but we can work out > the details later). > > What we want to provide are tools that ISPs can use to engineer > multicast traffic. MPLS and constraint based routing allow us to build > those tools. ISPs can then used them to engineer multicast traffic from > certain groups to go on certain paths only or to decrease the fanout for > eg. All the pieces may not be implemented or specified yet, but i think > we have a framework to build these tools. I think that the whole issue of traffic engineering for multicast within an ISP may be of *practical* significance only when the amount of multicast traffic forms a *significant* percentage of the total traffic within an ISP. So, how many ISPs have today more than let say 20% of their total traffic as *native* (as opposed to tunneled) multicast ? Yakov. From owner-pim@catarina.usc.edu Thu May 27 08:19:05 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26352 for ; Thu, 27 May 1999 08:19:04 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id FAA02943 for pim-list; Thu, 27 May 1999 05:11:57 -0700 Received: from adn.alcatel.com (postman.adn.alcatel.com [198.205.32.33]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id FAA02939 for ; Thu, 27 May 1999 05:11:52 -0700 Received: from postal.adn.alcatel.com (postal [198.205.32.56]) by adn.alcatel.com with ESMTP (8.7.6/8.7.1) id IAA18995 for ; Thu, 27 May 1999 08:06:25 -0400 (EDT) Received: from adn.alcatel.com ([198.205.54.160]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA11CB; Thu, 27 May 1999 08:12:30 -0400 Message-ID: <374D368C.59DA910@adn.alcatel.com> Date: Thu, 27 May 1999 08:11:57 -0400 From: Liwen Wu Organization: Alcatel X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Dino Farinacci , mpls@UU.NET, pim@catarina.usc.edu Subject: Re: Traffic Engineering for multicast traffic References: <199905270024.RAA15345@flipper.cisco.com> <374D3423.CA5DAC14@adn.alcatel.com> Content-Type: multipart/mixed; boundary="------------3B6EECE9244AC817AB090806" Sender: owner-pim@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. --------------3B6EECE9244AC817AB090806 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There is also one more point on this: If a multicast tree does not have a lot of receivers, and the receivers are quite static(no dynamic join/leave), RSVP can be use. In this situation, the whole explicited tree (which is not a big object for a small tree) can piggybacked in RSVP path msg. best regards, Liwen-- Liwen Wu wrote: > Dino Farinacci wrote: > > > >> What I am try to propose is to have ONLY the leaf choose the whole > > >> reverse path from the leaf all the way to root. All the other on-tree nodes > > >> just > > >> follow the reverse path that leaf has choosen. This idea is very similar to > > >> the source routing concept in unicast routing, where the first router choose > > >> the > > >> the whole path. > > > > Why would you want to consider doing it this way. You'd have to invent > > a new mechanism to find: > > > > 1) the root of the tree > > 2) the path to the root of the tree > > No, you can still use the same way that how you choose your RP today. Then > the leaf computes the whole reverse path to this root according to its own topology > database or by some other mechanism(e.g. "manager" mentioned in QoSMIC, > or NMS) > > > > > > > And if you didn't do this apriori to someone joining the group, you'd have > > longer join latencies then today's schemes. > > > > And to find the path of the tree which has "available" or "non-congested" > > resources would be inventing some the TR stuff going on in unicast > > routing. > > Unicast routing is alway doing this today for unicast traffic engineering. > > > > > > > >> 1) Only the leaf nodes is making the selection of the reverse path. It is > > >> easier especially > > >> if QoS/COS gets involved. For example, in a network, some nodes are running > > >> with release 1 code, and some nodes are running with release 2 code. There > > >> maybe > > >> a very minor difference in reverseQOS path selection logic, letting each > > >> on-tree node > > >> choose its parent independently might be harder than only letting the leaf > > >> making > > >> the decision. > > > > You want to design a new protocol/mechanism to deal with different > > software releases. I think there are better/(more local) ways to solve > > this. > > > > Also, doing path selection in one place doesn't make it any simpler. > > > > >> 2) Very similar to unicast traffic engineering, the leaf node can prune all the > > >> congested > > >> links and nodes out before doing the calculation. > > > > You could do this with hop-by-hop state too. > > Same argument here as why people is doing source routing for unicast traffic in > addition to hop-by-hop routing. > > > > > > > >> 3) Also, if you want to build a colored tree, the leaf can calculate the > > >> reverse colord > > >> path use only the same color links and same color nodes. > > > > A colored tree is just like joining another group. > > > > So let's step back and ask what problem you are trying to solve? At first, > > I thought you wanted to solve the fanout issue at any one node. Meaning, > > say we have a fanout of 8 interfaces in a Chicago router that could be > > split to have 4 in a Houston router and 4 in the Chicago router. > > > > If this is one of the issues you wanted to address, why would this be > > a good thing. It sounds like you'd be pushing the fanout higher towards > > the root. I don't see providers wanting to do that. They don't want to > > fanout transit traffic, they want fanout to their own customer receivers > > and push the responsiblity of replication on their peers, if they can. > > Yes, you raised a very good example here. When there are thousands > of mulitcast groups in a backbone carrier network, > 1) for some groups, you want to push fanout higher, and > 2) for some groups you want to push fanout lower, also > 3) for some group you want to choose certain fanout point > 4) for some group you want to avoid certain fanout point. > > Also, if some group trees requires certain QoS/COS constraints. > > I would thought multicast traffic engineering can help to solve these problems. > > And to support this, PIM-SM seems not that hard with only following > extensions: > > 1) a new PIM-SM msg, JOIN-ACK/JOIN-NAK > > 2) a new object(fields) in JOIN msg which carry the reverse explicit > path and QoS/COS contraints > > 3) At any on-tree node(merge point, or fanout point), merge these > explicit path, and send 1 JOIN with QoS/COS contraint towards > the RP > > best regards, > Liwen-- > > > > > > > So, I'd like to hear a clear description of the problem you want to solve. > > > > Dino > > > > --------------3B6EECE9244AC817AB090806 Content-Type: text/x-vcard; charset=us-ascii; name="liwen.wu.vcf" Content-Description: Card for Liwen Wu Content-Disposition: attachment; filename="liwen.wu.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Wu;Liwen tel;fax:703-724-2003 tel;work:703-724-2619 x-mozilla-html:FALSE org:Alcatel;R&D version:2.1 email;internet:liwen.wu@adn.alcatel.com adr;quoted-printable:;;44983 Knoll Square=0D=0A;Ashburn;VA;20147;U.S.A x-mozilla-cpt:;18304 fn:Liwen Wu end:vcard --------------3B6EECE9244AC817AB090806-- From owner-pim@catarina.usc.edu Thu May 27 08:21:03 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26398 for ; Thu, 27 May 1999 08:21:01 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id FAA03014 for pim-list; Thu, 27 May 1999 05:17:49 -0700 Received: from maile.surrey.ac.uk (maile.surrey.ac.uk [131.227.102.10]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id FAA03010 for ; Thu, 27 May 1999 05:17:43 -0700 Received: from petra.ee.surrey.ac.uk by maile.surrey.ac.uk with SMTP (PP); Thu, 27 May 1999 13:16:53 +0100 Date: Thu, 27 May 1999 13:17:04 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: mpls@UU.NET To: Masataka Ohta cc: Cheng-Yin Lee , dino@cisco.com, liwen.wu@adn.alcatel.com, mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk Subject: Re: Traffic Engineering for multicast traffic In-Reply-To: <199905270817.RAA12019@necom830.hpcl.titech.ac.jp> Message-ID: Organization: speaking for none X-URL: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk On Thu, 27 May 1999, Masataka Ohta wrote: > From the fact that multicast route aggregation is impossible, > it can directly be derived that MPLS is useless for multicast. I'm sorry, I don't see how you get from a) to b). Can you please elaborate on this compelling argument? Feel free to compare multicast over MPLS with multicast using EARTH/MARS/VENUS when you do. > You don't even have to consider policy/QoS. > > However, this is a useless arguement, because MPLS a cousin of > ATM and is useless for anything. MPLS appears quite useful for implementing IP routing where it can be leveraged to IP's benefit. But, hey, what do I know? Followups set to the mpls list. L. > Masataka Ohta PGP From owner-pim@catarina.usc.edu Thu May 27 08:42:49 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26881 for ; Thu, 27 May 1999 08:42:47 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id FAA03090 for pim-list; Thu, 27 May 1999 05:36:03 -0700 Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id FAA03086 for ; Thu, 27 May 1999 05:35:59 -0700 Received: from zcard00m.ca.nortel.com (actually 47.2.0.111) by smtprich.nortel.com; Thu, 27 May 1999 07:35:49 -0500 Received: from zcard008.bnr.ca (zcard008.ca.nortel.com [47.127.82.62]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id L3435HH1; Thu, 27 May 1999 08:35:40 -0400 Received: from nortel.com (zmerh02h.ca.nortel.com [47.169.33.100]) by zcard008.bnr.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id LNKY1K02; Thu, 27 May 1999 08:35:39 -0400 Message-ID: <374D2C5E.F2AA3409@nortel.com> Date: Thu, 27 May 1999 07:28:30 -0400 From: "Cheng-Yin Lee" X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter CC: Dino Farinacci , liwen.wu@adn.alcatel.com, mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk Subject: Re: Traffic Engineering for multicast traffic References: <199905271212.FAA22146@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Yakov Rekhter wrote: > > I think that the whole issue of traffic engineering for multicast > within an ISP may be of *practical* significance only when the amount > of multicast traffic forms a *significant* percentage of the total > traffic within an ISP. So, how many ISPs have today more than let say > 20% of their total traffic as *native* (as opposed to tunneled) > multicast ? If we can assume the traffic will _never_ grow then sure, we don't have to worry about traffic engineering. cheers, cyl From owner-pim@catarina.usc.edu Thu May 27 09:11:11 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27773 for ; Thu, 27 May 1999 09:11:09 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id GAA03186 for pim-list; Thu, 27 May 1999 06:07:32 -0700 Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id GAA03182 for ; Thu, 27 May 1999 06:07:28 -0700 Received: from ihgp3.ih.lucent.com (h135-1-27-103.lucent.com [135.1.27.103]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA15799 for ; Thu, 27 May 1999 09:07:26 -0400 (EDT) Received: by ihgp3.ih.lucent.com (8.8.8+Sun/EMS-1.4 sol2) id IAA20246; Thu, 27 May 1999 08:07:05 -0500 (CDT) Cc: Dino Farinacci , mpls@UU.NET, pim@catarina.usc.edu Received: from il0015venki1.ih.lucent.com by ihgp3.ih.lucent.com (8.8.8+Sun/EMS-1.4 sol2) id IAA20123; Thu, 27 May 1999 08:06:51 -0500 (CDT) Date: Thu, 27 May 1999 08:07:07 -0500 (Central Daylight Time) From: "R. Venkateswaran" Reply-To: "r. venkateswaran" To: Liwen Wu Original-cc: Dino Farinacci , mpls@UU.NET, pim@catarina.usc.edu Subject: Re: Traffic Engineering for multicast traffic In-Reply-To: <374D3423.CA5DAC14@adn.alcatel.com> Message-ID: X-X-Sender: venki@ihgp3.ih.lucent.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk Liwen, > Yes, you raised a very good example here. When there are thousands > of mulitcast groups in a backbone carrier network, > 1) for some groups, you want to push fanout higher, and > 2) for some groups you want to push fanout lower, also > 3) for some group you want to choose certain fanout point > 4) for some group you want to avoid certain fanout point. > > Also, if some group trees requires certain QoS/COS constraints. > > I would thought multicast traffic engineering can help to solve these problems. > > And to support this, PIM-SM seems not that hard with only following > extensions: > > 1) a new PIM-SM msg, JOIN-ACK/JOIN-NAK > > 2) a new object(fields) in JOIN msg which carry the reverse explicit > path and QoS/COS contraints > > 3) At any on-tree node(merge point, or fanout point), merge these > explicit path, and send 1 JOIN with QoS/COS contraint towards > the RP Maybe it is just me, I just don't understand how this is so simple. First, when you talk about QoS/COS constraints, do you refer *only* to bandwidth. If so, then it is quite clear to me. If you have QoS constraints based on delay, packet loss and delay jitter, how do you ensure that a new path from a "fanout" node (node that is already on the tree and the new JOIN message reaches this node) to the root (or RP) does not violate the QoS constraints of already existing receivers? Do you maintain all the QoS requirements of existing receivers at the "fanout" point? QoS constraints for delay etc are end-to-end constraints, not link-by-link constraints. So, it is going to be extremely difficult to calculate link-by-link constraints based on end-to-end constraints. Of course, this is trivial for bandwidth only. Second, there is the join latency, which Dino has already explained in his mail. Other than the JOIN-ACK/JOIN-NAK, there is also the latency involved with informing *all* the nodes on the multicast tree about the new path to the root. Currently, in PIM-SM, the JOIN latency is a one-way trip to the RP. What you are proposing is a round-trip plus some more. I am not sure whether a single join should involve all the nodes in the multicast tree. My 2 cents. Regards, venki -- R. Venkateswaran (Venki) [email -> mailto:venki@lucent.com ] [Lucent Technologies Bell Labs (IHP), Room 2E-241,Ph # (630)-979-6253] From owner-pim@catarina.usc.edu Thu May 27 11:17:57 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00772 for ; Thu, 27 May 1999 11:17:57 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA03503 for pim-list; Thu, 27 May 1999 08:08:20 -0700 Received: from mail2.lancs.ac.uk ([148.88.8.13]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id IAA03499 for ; Thu, 27 May 1999 08:08:09 -0700 Received: from mail2.lancs.ac.uk (actually host localhost) by mail2.lancs.ac.uk with Local SMTP (PP); Thu, 27 May 1999 16:04:50 +0100 Received: from ufs1.lancs.ac.uk (ufs1.lancs.ac.uk [148.88.16.113]) by mail2.lancs.ac.uk with SpooMTA 1.24; Thu, 27 May 1999 16:04:50 +0000 Received: from lancaster.ac.uk (egc015000006.lancs.ac.uk [148.88.154.120]) by ufs1.lancs.ac.uk (8.8.4/8.6.12) with ESMTP id QAA07718; Thu, 27 May 1999 16:05:55 +0100 (BST) Message-ID: <374D5FC8.C4C94AC7@lancaster.ac.uk> Date: Thu, 27 May 1999 16:07:52 +0100 From: Shravan Goorah Reply-To: s.goorah@lancaster.ac.uk Organization: University of Lancaster X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Cheng-Yin Lee CC: Yakov Rekhter , Dino Farinacci , liwen.wu@adn.alcatel.com, mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk Subject: Re: Traffic Engineering for multicast traffic References: <199905271212.FAA22146@omega.cisco.com> <374D2C5E.F2AA3409@nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello Cyl, Cheng-Yin Lee wrote: > Yakov Rekhter wrote: > > > > I think that the whole issue of traffic engineering for multicast > > within an ISP may be of *practical* significance only when the amount > > of multicast traffic forms a *significant* percentage of the total > > traffic within an ISP. So, how many ISPs have today more than let say > > 20% of their total traffic as *native* (as opposed to tunneled) > > multicast ? > > If we can assume the traffic will _never_ grow then sure, we don't have > to worry about traffic engineering. > > cheers, > cyl Your proposal seems interesting - can you explain how you come to such an assumption... Cheers, Shravan From owner-pim@catarina.usc.edu Thu May 27 14:01:11 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02883 for ; Thu, 27 May 1999 14:01:10 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA03979 for pim-list; Thu, 27 May 1999 10:55:07 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA03975 for ; Thu, 27 May 1999 10:55:01 -0700 From: Masataka Ohta Message-Id: <199905271741.CAA12568@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id CAA12568; Fri, 28 May 1999 02:41:21 +0900 Subject: Re: Traffic Engineering for multicast traffic To: mpls@UU.NET Date: Fri, 28 May 99 2:41:21 JST Cc: mohta@necom830.hpcl.titech.ac.jp, leecy@nortelnetworks.com, dino@cisco.com, liwen.wu@adn.alcatel.com, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk In-Reply-To: ; from "Lloyd Wood" at May 27, 99 1:17 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-pim@catarina.usc.edu Precedence: bulk Lloyd; MPLS was first proposed to show that we don't need NHRP. Nothing more than that. When I did so, I was fully aware that it scales poorly for best effort traffic. I was fully aware that cell swithcing routers are much slower than packet routers, too. As we have virtually no PNNI today, we don't have to mind NHPR nor MPLS. The only thing you should know about MPLS is that "traffic engineering" is not the magic word to improve the poor scalability. > > From the fact that multicast route aggregation is impossible, > > it can directly be derived that MPLS is useless for multicast. > > I'm sorry, I don't see how you get from a) to b). I can give you a hint. The magic keyword to dismiss useless protocols is "scalability". > Followups set to the mpls list. Do you think I am (or was) there? Masataka Ohta From owner-pim@catarina.usc.edu Thu May 27 15:31:10 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03979 for ; Thu, 27 May 1999 15:31:09 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA04654 for pim-list; Thu, 27 May 1999 12:22:22 -0700 Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA04646 for ; Thu, 27 May 1999 12:22:17 -0700 Received: (dino@localhost) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id MAA14266; Thu, 27 May 1999 12:21:41 -0700 (PDT) Date: Thu, 27 May 1999 12:21:41 -0700 (PDT) Message-Id: <199905271921.MAA14266@flipper.cisco.com> From: Dino Farinacci To: liwen.wu@adn.alcatel.com CC: mpls@UU.NET, pim@catarina.usc.edu In-reply-to: <374D3423.CA5DAC14@adn.alcatel.com> (message from Liwen Wu on Thu, 27 May 1999 08:01:39 -0400) Subject: Re: Traffic Engineering for multicast traffic Sender: owner-pim@catarina.usc.edu Precedence: bulk >> Unicast routing is alway doing this today for unicast traffic engineering. Right, and multicast should use it. There was a comment (forgot who) that it shouldn't be topology based. Well, if unicast routing is already doing it, it should be topology based. >> And to support this, PIM-SM seems not that hard with only following >> extensions: >> >> 1) a new PIM-SM msg, JOIN-ACK/JOIN-NAK Naming the message type provides no value in describing what the message does. >> 2) a new object(fields) in JOIN msg which carry the reverse explicit >> path and QoS/COS contraints >> >> 3) At any on-tree node(merge point, or fanout point), merge these >> explicit path, and send 1 JOIN with QoS/COS contraint towards >> the RP Sounds exactly like RSVP to me. Dino From owner-pim@catarina.usc.edu Thu May 27 15:38:47 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04082 for ; Thu, 27 May 1999 15:38:44 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA04832 for pim-list; Thu, 27 May 1999 12:33:55 -0700 Received: from maile.surrey.ac.uk (maile.surrey.ac.uk [131.227.102.10]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id MAA04828 for ; Thu, 27 May 1999 12:33:50 -0700 Received: from petra.ee.surrey.ac.uk by maile.surrey.ac.uk with SMTP (PP); Thu, 27 May 1999 20:33:07 +0100 Date: Thu, 27 May 1999 20:33:33 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Dino Farinacci cc: mohta@necom830.hpcl.titech.ac.jp, mpls@UU.NET, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk Subject: Re: Traffic Engineering for multicast traffic In-Reply-To: <199905271927.MAA16036@flipper.cisco.com> Message-ID: Organization: speaking for none X-URL: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk On Thu, 27 May 1999, Dino Farinacci wrote: > >> The magic keyword to dismiss useless protocols is "scalability". > > And "scalability" is such an overloaded (and sometimes over-rated) term. Right. I mean, a finite 128-bit address space for IPv6? Not scalable. Useless, in fact. Right, so much for IPv6. If that's the best argument he can come up with... L. scalability has to be played off against suitability for purpose. PGP From owner-pim@catarina.usc.edu Thu May 27 15:47:28 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04196 for ; Thu, 27 May 1999 15:47:26 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA04715 for pim-list; Thu, 27 May 1999 12:28:22 -0700 Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA04711 for ; Thu, 27 May 1999 12:28:18 -0700 Received: (dino@localhost) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id MAA16036; Thu, 27 May 1999 12:27:34 -0700 (PDT) Date: Thu, 27 May 1999 12:27:34 -0700 (PDT) Message-Id: <199905271927.MAA16036@flipper.cisco.com> From: Dino Farinacci To: mohta@necom830.hpcl.titech.ac.jp CC: mpls@UU.NET, mohta@necom830.hpcl.titech.ac.jp, leecy@nortelnetworks.com, liwen.wu@adn.alcatel.com, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk In-reply-to: <199905271741.CAA12568@necom830.hpcl.titech.ac.jp> (message from Masataka Ohta on Fri, 28 May 99 2:41:21 JST) Subject: Re: Traffic Engineering for multicast traffic Sender: owner-pim@catarina.usc.edu Precedence: bulk >> The magic keyword to dismiss useless protocols is "scalability". And "scalability" is such an overloaded (and sometimes over-rated) term. Dino From owner-pim@catarina.usc.edu Thu May 27 16:16:32 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04535 for ; Thu, 27 May 1999 16:16:32 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA05088 for pim-list; Thu, 27 May 1999 13:12:47 -0700 Received: from adn.alcatel.com (postman.adn.alcatel.com [198.205.32.33]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA05084 for ; Thu, 27 May 1999 13:12:40 -0700 Received: from postal.adn.alcatel.com (postal [198.205.32.56]) by adn.alcatel.com with ESMTP (8.7.6/8.7.1) id QAA11961 for ; Thu, 27 May 1999 16:07:12 -0400 (EDT) Received: from adn.alcatel.com ([198.205.54.160]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA4F40; Thu, 27 May 1999 16:13:19 -0400 Message-ID: <374DA73E.CCD609A5@adn.alcatel.com> Date: Thu, 27 May 1999 16:12:47 -0400 From: Liwen Wu Organization: Alcatel X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Dino Farinacci CC: mpls@UU.NET, pim@catarina.usc.edu Subject: Re: Traffic Engineering for multicast traffic References: <199905271921.MAA14266@flipper.cisco.com> Content-Type: multipart/mixed; boundary="------------139AD2803B16097EF2BA26C7" Sender: owner-pim@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. --------------139AD2803B16097EF2BA26C7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dino Farinacci wrote: > >> Unicast routing is alway doing this today for unicast traffic engineering. > > Right, and multicast should use it. There was a comment (forgot who) that > it shouldn't be topology based. Well, if unicast routing is already doing > it, it should be topology based. > > >> And to support this, PIM-SM seems not that hard with only following > >> extensions: > >> > >> 1) a new PIM-SM msg, JOIN-ACK/JOIN-NAK > > Naming the message type provides no value in describing what the message > does. I agree. But if we can agree on the idea, we can always work out the details later. The idea is: To build a receiver-initiated explicit multicast tree, the leaf (or border router) specify the whole reverse path towards root (or RP) and each individual on-tree node join the upstream node (parent) according to the reverse path specified by the leaf node. To build a sender-initiated explicit multicast tree, the root of the tree specify the whole tree and set it up from root to all the receivers. I would thought PIM-SM can be used to set up receiver-initiated explicit multicast tree, whereas RSVP can be used to setup sender-initiated explicit multicast tree. Receiver-initiated explicit multicast tree is more suitable for a tree which has a lot of receivers(or more wider, or high fanout). Sender-initiated explicit multicast tree is more suitable for a tree which has fewer receivers(or low fanout), so that a whole explicit tree can be piggybacked in RSVP PATH msg. > > > >> 2) a new object(fields) in JOIN msg which carry the reverse explicit > >> path and QoS/COS contraints > >> > >> 3) At any on-tree node(merge point, or fanout point), merge these > >> explicit path, and send 1 JOIN with QoS/COS contraint towards > >> the RP > > Sounds exactly like RSVP to me. No, RSVP PATH msg(in explicit multicast tree scenario) picks the fanout point from root towards downstream, whereas in PIM-SM the JOIN msg (in explicit multicast tree scenario) picks the fanout point from downstream towards upstream. best regards, Liwen-- > > > Dino > --------------139AD2803B16097EF2BA26C7 Content-Type: text/x-vcard; charset=us-ascii; name="liwen.wu.vcf" Content-Description: Card for Liwen Wu Content-Disposition: attachment; filename="liwen.wu.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Wu;Liwen tel;fax:703-724-2003 tel;work:703-724-2619 x-mozilla-html:FALSE org:Alcatel;R&D version:2.1 email;internet:liwen.wu@adn.alcatel.com adr;quoted-printable:;;44983 Knoll Square=0D=0A;Ashburn;VA;20147;U.S.A x-mozilla-cpt:;18304 fn:Liwen Wu end:vcard --------------139AD2803B16097EF2BA26C7-- From owner-pim@catarina.usc.edu Thu May 27 16:26:27 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04639 for ; Thu, 27 May 1999 16:26:27 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA05197 for pim-list; Thu, 27 May 1999 13:23:33 -0700 Received: from adn.alcatel.com (postman.adn.alcatel.com [198.205.32.33]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA05189 for ; Thu, 27 May 1999 13:23:25 -0700 Received: from postal.adn.alcatel.com (postal [198.205.32.56]) by adn.alcatel.com with ESMTP (8.7.6/8.7.1) id QAA12426 for ; Thu, 27 May 1999 16:17:57 -0400 (EDT) Received: from adn.alcatel.com ([198.205.54.160]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA50B0; Thu, 27 May 1999 16:24:03 -0400 Message-ID: <374DA9C4.9D215714@adn.alcatel.com> Date: Thu, 27 May 1999 16:23:32 -0400 From: Liwen Wu Organization: Alcatel X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET CC: Masataka Ohta , Cheng-Yin Lee , dino@cisco.com, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk Subject: Re: Traffic Engineering for multicast traffic References: Content-Type: multipart/mixed; boundary="------------C67A30F872DE54D6F09281E2" Sender: owner-pim@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. --------------C67A30F872DE54D6F09281E2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lloyd Wood wrote: > On Thu, 27 May 1999, Masataka Ohta wrote: > > > From the fact that multicast route aggregation is impossible, > > it can directly be derived that MPLS is useless for multicast. > > I'm sorry, I don't see how you get from a) to b). > > Can you please elaborate on this compelling argument? Feel free to > compare multicast over MPLS with multicast using EARTH/MARS/VENUS when > you do. > > > You don't even have to consider policy/QoS. > > > > However, this is a useless arguement, because MPLS a cousin of > > ATM and is useless for anything. > > MPLS appears quite useful for implementing IP routing where it can be > leveraged to IP's benefit. But, hey, what do I know? MPLS Multicast tree can be useful in the following example: 1) In a core backbone network, if a couple of multicast groups coming in from a same ingress point and exits the same egress points, 2) you can build ONE MPLS traffic engineering tree which is rooted at this ingress point and exits the same egress points. 3) then ingress node can put all the multicast traffic for these groups onto this single MPLS traffic engineering tree. 4) there is no requirement on the relationship of these multicast group addresses(they don't need to be aggregatable) best regards, Liwen-- > > > Followups set to the mpls list. > > L. > > > Masataka Ohta > > PGP --------------C67A30F872DE54D6F09281E2 Content-Type: text/x-vcard; charset=us-ascii; name="liwen.wu.vcf" Content-Description: Card for Liwen Wu Content-Disposition: attachment; filename="liwen.wu.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Wu;Liwen tel;fax:703-724-2003 tel;work:703-724-2619 x-mozilla-html:FALSE org:Alcatel;R&D version:2.1 email;internet:liwen.wu@adn.alcatel.com adr;quoted-printable:;;44983 Knoll Square=0D=0A;Ashburn;VA;20147;U.S.A x-mozilla-cpt:;18304 fn:Liwen Wu end:vcard --------------C67A30F872DE54D6F09281E2-- From owner-pim@catarina.usc.edu Thu May 27 16:30:07 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04687 for ; Thu, 27 May 1999 16:30:06 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA05138 for pim-list; Thu, 27 May 1999 13:17:44 -0700 Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA05134 for ; Thu, 27 May 1999 13:17:30 -0700 Received: (dino@localhost) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id NAA27706; Thu, 27 May 1999 13:16:56 -0700 (PDT) Date: Thu, 27 May 1999 13:16:56 -0700 (PDT) Message-Id: <199905272016.NAA27706@flipper.cisco.com> From: Dino Farinacci To: liwen.wu@adn.alcatel.com CC: mpls@UU.NET, pim@catarina.usc.edu In-reply-to: <374DA73E.CCD609A5@adn.alcatel.com> (message from Liwen Wu on Thu, 27 May 1999 16:12:47 -0400) Subject: Re: Traffic Engineering for multicast traffic Sender: owner-pim@catarina.usc.edu Precedence: bulk >> I agree. But if we can agree on the idea, we can always work out the details >> later. I would like to discuss the problem much more before looking at ideas and solutions. >> I would thought PIM-SM can be used to set up receiver-initiated explicit >> multicast tree, whereas RSVP can be used to setup sender-initiated explicit >> multicast tree. RSVP doesn't set up multicast trees. >> Sender-initiated explicit multicast tree is more suitable for a tree which >> has fewer receivers(or low fanout), so that a whole explicit tree can be >> piggybacked in RSVP PATH msg. It is more suitable because it couldn't scale for large number of receivers. >> No, RSVP PATH msg(in explicit multicast tree scenario) picks the fanout >> point from root towards downstream, whereas in PIM-SM the JOIN msg >> (in explicit multicast tree scenario) picks the fanout point from downstream >> towards upstream. No, you are wrong. RSVP uses the multicast tree which has already been built by your favorite multicast routing protocol. The fanout of PATH messages has already been determined before the message is set. It is the receivers which initiate reservations, so the merge semantics you describe are already performed in RSVP. Dino From owner-pim@catarina.usc.edu Thu May 27 17:41:18 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05378 for ; Thu, 27 May 1999 17:41:17 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id OAA05468 for pim-list; Thu, 27 May 1999 14:25:46 -0700 Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id OAA05464 for ; Thu, 27 May 1999 14:25:30 -0700 Received: from tossu (pelican.sms.fi [192.58.51.9]) by silver.sms.fi (8.9.2/8.9.2) with SMTP id AAA16409; Fri, 28 May 1999 00:24:51 +0300 (EEST) (envelope-from pete@sms.fi) Message-ID: <005b01bea887$3b591de0$137a6fc2@sms.fi> From: "Petri Helenius" To: "Dino Farinacci" , Cc: , , , , , References: <199905271927.MAA16036@flipper.cisco.com> Subject: Re: Traffic Engineering for multicast traffic Date: Fri, 28 May 1999 00:23:44 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit > >> The magic keyword to dismiss useless protocols is "scalability". > > And "scalability" is such an overloaded (and sometimes over-rated) term. > ...and there are lessons to be remembered from the DVMRP and pre-MSDP PIM days that insisting on technical perfection does not make things happen in real life. (quite the contrary) Pete From owner-pim@catarina.usc.edu Thu May 27 22:02:35 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07734 for ; Thu, 27 May 1999 22:02:34 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id SAA06385 for pim-list; Thu, 27 May 1999 18:59:48 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id SAA06381 for ; Thu, 27 May 1999 18:59:43 -0700 From: Masataka Ohta Message-Id: <199905280140.KAA14266@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA14266; Fri, 28 May 1999 10:40:42 +0900 Subject: Re: Traffic Engineering for multicast traffic To: liwen.wu@adn.alcatel.com (Liwen Wu) Date: Fri, 28 May 99 10:40:40 JST Cc: mpls@UU.NET, mohta@necom830.hpcl.titech.ac.jp, leecy@nortelnetworks.com, dino@cisco.com, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk In-Reply-To: <374DA9C4.9D215714@adn.alcatel.com>; from "Liwen Wu" at May 27, 99 4:23 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-pim@catarina.usc.edu Precedence: bulk Liwen; > 4) there is no requirement on the relationship of these multicast group > addresses(they don't need to be aggregatable) They don't need to be aggregatable. They don't need MPLS encapsulation, either. Masataka Ohta From owner-pim@catarina.usc.edu Thu May 27 22:06:17 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07760 for ; Thu, 27 May 1999 22:06:16 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id TAA06438 for pim-list; Thu, 27 May 1999 19:04:02 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id TAA06434 for ; Thu, 27 May 1999 19:03:58 -0700 From: Masataka Ohta Message-Id: <199905280119.KAA14217@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA14217; Fri, 28 May 1999 10:19:24 +0900 Subject: Re: Traffic Engineering for multicast traffic To: dino@cisco.com (Dino Farinacci) Date: Fri, 28 May 99 10:19:23 JST Cc: mohta@necom830.hpcl.titech.ac.jp, mpls@UU.NET, leecy@nortelnetworks.com, liwen.wu@adn.alcatel.com, pim@catarina.usc.edu, idmr@cs.ucl.ac.uk In-Reply-To: <199905271927.MAA16036@flipper.cisco.com>; from "Dino Farinacci" at May 27, 99 12:27 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-pim@catarina.usc.edu Precedence: bulk > >> The magic keyword to dismiss useless protocols is "scalability". > > And "scalability" is such an overloaded (and sometimes over-rated) term. It keeps those who overload it from the truth, which is a good thing unless I tried to discuss with them. Masataka Ohta From owner-pim@catarina.usc.edu Fri May 28 17:02:38 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01949 for ; Fri, 28 May 1999 17:02:37 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA09325 for pim-list; Fri, 28 May 1999 13:23:27 -0700 Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA09321 for ; Fri, 28 May 1999 13:23:23 -0700 Received: (lwei@localhost) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id NAA16929; Fri, 28 May 1999 13:22:52 -0700 (PDT) Date: Fri, 28 May 1999 13:22:52 -0700 (PDT) Message-Id: <199905282022.NAA16929@flipper.cisco.com> From: Liming Wei To: pim@catarina.usc.edu Subject: [mbeaulie@ietf.org: 45th IETF-OSLO, NORWAY: PIM] Sender: owner-pim@catarina.usc.edu Precedence: bulk Folks, The PIM Working Group is scheduled to meet on Tuesday 9-11:30am in Oslo. Here is a tentative agenda just go give everyone an idea about how full the time is. Tom might have a final list that is even longer. o Status report on PIM-DM, PIM-SM, PIM authentication drafts (20 mins) o Bidirectional tree PIM (Deborah 30 mins) o Tom Pusateri (20 mins) o PIM DM State-Refresh (Isidor Kouvelas, 20 mins) o Simple Key Management for PIM (Thomas Hardjono 20 mins) o PIM-SM security "Billy C. Ng" ( 25 min) -Liming ------- Start of forwarded message ------- From: Marcia Beaulieu Subject: 45th IETF-OSLO, NORWAY: PIM PIM is tentatively scheduled as follows: Tuesday, July 13 at 0900-1130 other groups scheduled at that time: xmlsig, ngtrans, megaco Please submit an agenda for this meeting as soon as possible to agenda@ietf.org The deadline for submitting an agenda is July 1 at 1200 ET. Thanks, Marcia ------- End of forwarded message -------