The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Invitation to discuss: "P2MP problem statement"
Loa,
Positive. P2MP LSPs may have some very interesting applications.
Ron
> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Loa
> Andersson
> Sent: Wednesday, September 03, 2003 3:37 AM
> To: mpls@UU.NET
> Cc: Loa Andersson
> Subject: Re: Invitation to discuss: "P2MP problem statement"
>
>
> Working Group,
>
> it is almost three weeks since I sent this "invitation to
> discuss the P2MP probelm statement". The tendency has been
> mostly in favor of adding p2mp mpls as a new milestone to
> our charter, but the discussion has not been that active,
> so it is hard to decide one way or another. Apart from the
> authors (the author groups is about 12 people) it is only
> one person that has taken part in the discussion.
>
> I'm aware of that we had a mailing list problem, but it is
> my take that the mails gone through eventually, if you think
> this is wrong please resend.
>
> Before deciding I would like a quick "show of hands", just
> positive or negative. If you have reasons not to send your
> response to the list, you may send it directly to me.
>
> I plan to make the call mid-next week.
>
> /Loa
>
> Loa Andersson wrote:
>
> > 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
>
>
|
|