The MPLS WG Archive

[Loa Andersson <loa@pi.se>]

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