The MPLS WG Archive

[Ali Boudani <aboudani@irisa.fr>]

I found it very interresting ..

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