Subject: P2MP problem statement

From: Kullberg Alan-G19424 <[email-masked]>
Date: Wed, 13 Aug 2003 15:00:58 -0500

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.

---

From: Loa Andersson <[email-masked]>
Date: Wed, 13 Aug 2003 23:34:15 +0200

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

-- 
Loa Andersson

Mobile          +46 739 81 21 64
Email           [email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 18 Aug 2003 00:19:20 +0100

> the pros and cons to speak up. Silence will not be interpreted

Loa,

I consider point-to-mutlitpoint services to be important in MPLS and GMPLS networks and
believe that they should receive attention from the IETF.

My question for you (or perhaps for the ADs) is whether this is MPLS or CCAMP work. This
is a distinction which is repeatedly fudged and I don't see any clear division of labor
between the two WGs.

Note that the problem as stated, and the applicability of the solutions is as useful in
optical or TDM networks as it is in packet-based MPLS networks.

The problem statement is well written and convincing (IMHO) although it only talks about
packet traffic. It would be useful if it either distinguished between packet and
non-packet traffic (aknowledging that GMPLS signaling may use similar mechnisms in the
future) or brought the two together in one problem statement.

I think it would be a good idea if the problem statement made an explicit non-goal the
computation of p2mp paths and the determination of split points.

While the problem statement describes the need to allow the addition of receivers to a
p2mp LSP it does not discuss 'leaf initiated join'. I believe this was a feature that was
considered useful in ATM and should either be included here or explicitly excluded with a
reason.

I wonder about the sense of the milestone that says "to produce a small number of solution
draft(s)" unless the objective is to produce several for the WG to choose between. We
would be well advised to avoid developing alternate solutions that go forward to RFC. Can
we not nip this in the bud by puting all the interested parties in a design team together
and having them come up with just one solution?

Cheers,
Adrian

---

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 18 Aug 2003 11:10:46 -0700 (PDT)

Hi Adrian,

> future) or brought the two together in one problem statement.

I think the problem statement should cover both packet and non-packet
traffic. We can clarify this in the problem statement.

> computation of p2mp paths and the determination of split points.

Ok.

> considered useful in ATM and should either be included here or explicitly excluded with a

This is getting into solution details. Leaf initiated join is one possible
way of adding receivers to a P2MP LSP. The problem statement was simply
trying to capture this requirement.

> would be well advised to avoid developing alternate solutions that go forward to RFC.
> Can we not nip this in the bud by puting all the interested parties in a
design team together
> and having them come up with just one solution?

There is collaborative work in progress on a requirements document, that
in turn will drive the solutions. Its premature to place boundaries on the solutions before the
requirements are well spelled out. This is what the problem statement was
trying to capture.

Thanks,
rahul

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Fri, 29 Aug 2003 11:34:27 -0400

Hi,

> > 1. the content of the problem statement

clear and well written - just some additional comments in line,

> >     that a new milestone om p2mp mpls should be added

Personally in favor of adding this item to the Charter.

>future) or brought the two together in one problem statement.

Altough some of the solutions will be applicable to both, I'm not sure that 
they should be combined in the same statement. Requirements for p2mp packet 
based LSPs are identified, this is less clear for non packet based networks.

>computation of p2mp paths and the determination of split points.

I would rather say that p2mp path computation should be a non explicit goal 
... instead of an explicit non-goal. Indeed, the algos do not have to be 
included in the solutions of course but each solution may have direct 
implications on p2mp path computation (in term of efficiency, ...) : as 
such, this aspect should not be excluded from the list of criteria to 
evaluate the respective possible solutions.

JP.