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@xxxxxxxxxxxx> 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@xxxxxx
> 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@xxxxx
>
|
