The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Invitation to discuss: "P2MP problem statement"
Working Group, it is almost three weeks since I sent this "invitation to discuss the P2MP probelm statement". The tendency has been mostly in favor of adding p2mp mpls as a new milestone to our charter, but the discussion has not been that active, so it is hard to decide one way or another. Apart from the authors (the author groups is about 12 people) it is only one person that has taken part in the discussion. I'm aware of that we had a mailing list problem, but it is my take that the mails gone through eventually, if you think this is wrong please resend. Before deciding I would like a quick "show of hands", just positive or negative. If you have reasons not to send your response to the list, you may send it directly to me. I plan to make the call mid-next week. /Loa Loa Andersson wrote: > Alan + both teams, > > thanks for preparing this! > > Working Group, > > below you will find the p2mp problem statement prepared by the > autors behind the drafts: > draft-yasukawa-mpls-rsvp-p2mp-02.txt > draft-raggarwa-mpls-p2mp-te-00.txt > > I would like to have your response on > > 1. the content of the problem statement > 2. whether the mpls working group should ask the ADs > that a new milestone om p2mp mpls should be added > to our charter > > If there is support we plan to take this as an separate item > (not include it in the more general charter update) to the > ADs. Again this is a question for which I would like boths > the pros and cons to speak up. Silence will not be interpreted > (one way or another). > > /Loa > > Kullberg Alan-G19424 wrote: > >> Loa & George, >> >> Below is a problem statement for point-to-multipoint using MPLS. >> This problem statement has been prepared jointly by the authors >> of the drafts: >> draft-yasukawa-mpls-rsvp-p2mp-02.txt >> draft-raggarwa-mpls-p2mp-te-00.txt >> >> Please use this problem statement as a basis to get the MPLS WG >> charter updated to include P2MP work. >> >> Thanks, >> Alan >> >> ######################### >> >> Problem statement >> >> >> Content Distribution (CD), Interactive multi-media (IMM), and VPN >> multicast >> are >> applications that are best supported with multicast capabilities. >> >> IP Multicast provides P2MP communication. However, there are no Traffic >> Engineering (TE) capabilities or QoS guarantees with existing IP >> multicast >> protocols. Note that diff-serv combined with IP multicast routing is not >> sufficient for P2MP applications for many of the same reasons that it >> is not >> sufficient for unicast applications - TE and CSPF are required to >> enable and >> scale the intelligent management of network resources, to prevent >> congestion, and >> to enable sub-second rerouting around network failures. >> >> One possible solution would be to setup multiple P2P TE LSPs, one to >> each of >> the >> required egress PEs. This requires replicating incoming packets to >> all the >> P2P >> LSPs at the ingress PE to accommodate multipoint communication. This >> is sub- >> optimal. It places the replication burden on the ingress PE and hence has >> very >> poor scaling characteristics. It also wastes bandwidth resources, >> memory and >> MPLS >> (e.g. label) resources in the network. >> >> Hence, to provide TE for a P2MP application in an efficient manner in a >> large >> scale environemnt, P2MP TE mechanisms are required. Existing MPLS P2P TE >> mechanisms have to be enhanced to support P2MP TE LSP setup. >> >> We propose that MPLS be enhanced to setup P2MP TE LSPs. This should be >> achieved >> without running a multicast routing protocol in the network core and with >> maximum >> re-use of the existing MPLS protocols. A P2MP LSP will be setup with TE >> constraints and will allow efficient packet replication at various >> branching >> points in the network. RSVP-TE will be used for setting up a P2MP LSP >> with >> enhancements to existing P2P TE LSP procedures. The P2MP TE LSP setup >> mechanism >> will include the ability to add/remove receivers to/from an existing P2MP >> LSP. >> >> The MPLS WG will specify only how to setup a P2MP TE LSP. The usage of >> this >> will >> be application dependent. >> >> (Milestones) >> >> To produce a requirement draft that specifies the scope, requirements, >> and >> issues >> to resolve for this enhancement by Minneapolis 2003 meeting. >> >> To produce a small number of solution draft(s) which specify protocol >> extensions, >> enhancements and mechanisms to fill the requirement and solve the above >> problem >> by spring 2004 IETF meeting. >> >> >> >> >> >> (Example) >> >> Consider the following figure. >> >> Source 1 (S1) >> | >> PE1 >> | | >> | | >> R2----PE3--P1 P2---PE2--Receiver 1 (R1) >> | >> PE4----R3 >> | >> | >> R4 >> >> Figure 1. >> >> The above figure shows PE1, PE2, PE3 and PE4. PE1 is attached to a >> traffic >> source that is generating traffic for a P2MP application. PE2, PE3 and >> PE4 >> are >> attached to receivers that are interested in receiving traffic for the >> application. The following are the objectives that we wish to achieve: >> >> a) Set up a P2MP TE LSP from PE1 to PE2, PE3 and PE4. >> b) Packet replication should be efficient. In this case, the branch >> node P1 >> should replicate incoming packets and send them to PE3 and PE4. >> c) The P2MP TE LSP should be setup by enhancing existing RSVP-TE >> P2P >> procedures and without running a multicast routing protocol >> in the >> network core. >> >> > -- Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se
|
|