The MPLS WG Archive

[Kullberg Alan-G19424 <alan.kullberg@motorola.com>]

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.