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"
Hi Loa, Indeed the problem statement is well written. A multcast MPLS TE facility will further enhance SP's ability to integrate real-time multicast traffic into our current QoS matrix with fast recovery. I am in support of adding this item to the WG charter. Regards, Raymond At 09:36 AM 9/3/2003 +0200, Loa Andersson wrote: >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 > >
|
|