The MPLS WG Archive

[Yuichi Ikejiri <y.ikejiri@ntt.com>]

Hi all,

I strongly support this P2MP problem statement, then request it to be
added in the charter. I think the requirement from the SPs perspective
is well reflected in this document.

Yuichi Ikejiri
NTT Communications 

On Mon, 08 Sep 2003 10:06:21 +0530
"S Mahadevan-A19066" <mahadevan.s@motorola.com> wrote:

> Loa,
> 
> Thats a very interesting problem. P2MP LSP should have a lot of
> interesting applications! I strongly endorse adding this problem
> to the charter..
> 
> Regards
> Mahadevan Sankar
> Motorola-India.
> 
> -----Original Message-----
> From: Loa Andersson
> To: Kullberg Alan-G19424; mpls@UU.NET
> Sent: 8/14/03 3:04 AM
> Subject: Invitation to discuss: "P2MP problem statement"
> 
> 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
>