The MPLS WG Archive

["LE ROUX Jean-Louis FTRD/DAC/LAN" <jeanlouis.leroux@rd.francetelecom.com>]

Hi Loa and all

1: This problem statement is IMHO very well written, and fits our
expectations.
As Adrian mentionned earlier, it could be good to highlight that routing
and tree computation are out of the scope.

2: I'm in favor of adding this item in the charter.

JL  

-----Message d'origine-----
De : Loa Andersson [mailto:loa@pi.se]
Envoye : mercredi 13 aout 2003 23:34
A : Kullberg Alan-G19424; mpls@UU.NET
Objet : 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