The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Sep> msg00008



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Invitation to discuss: "P2MP problem statement"

  • From: Jean Philippe Vasseur <jvasseur@cisco.com>
  • Date: Wed, 03 Sep 2003 06:07:23 -0400
  • Cc: mpls@UU.NET, Loa Andersson <loa@pi.se>

Hi Loa,

Not sure my mails has been received ... So I just resend: strongly in favor.

JP.

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
>
>