Subject: Re: Traffic Engineering for multicast traffic

From: John Crawford <[email-masked]>
Date: Fri, 4 Jun 1999 13:03:01 +0100 (British Summer Time)

Hello All,

Another benefit of explicit multicast trees (e.g. QoS 
multicast to heavyweight multicast groups) is the 
optimisation of the tree for cost.

jc.

On Tue, 25 May 1999 14:09:32 -0400 Liwen Wu 
<[email-masked]> wrote:

> Hello Bora Akyol,
> 
>   Please see my replies embedded in your comments.
> 
> Bora Akyol wrote:
> 
> > Liwen
> >
> > Can you please explain the differences between the way PIM-SM already works
> > and
> > your proposal?
> 
> A PIM-SM router, as far as I know today, join the upstream (parent) based on
> a unicast routing table(RPF checking). It is topology based.
> 
> What I am proposing is that:
> 
> 1) the receiver or a router (e.g border router) specify the whole reverse path
> along with the contraints(similar to the ones listed in Daniel O. Awduche's
> document) to RP and send the list along with the PIM JOIN msg towards RP.
> 
> 2) the PIM-SM routers along this reverse path  join the upstream according to
> the list
> specified in the PIM JOIN msg.
> 
> 
> 
> Also, what is performance gain obtained by using traffic engineered
> 
> > multicast trees vs standard trees. I can see the benefits of explicit
> > routing for unicast, but in a dynamic multicast environment where locality
> > of receivers may change rapidly, what benefits do the explicitly routed
> > multicast trees buy the network operator?
> 
> The environment that I have in mind is backbone network, not the campus
> network.
> 
> The benefits of explicit multicast trees over standard trees are very
> similar to the benefits of explicit traffic engineering tunnels.
> 
> Here are a couple of them, there are maybe more:
> 
> 1) If all the multicast trees in a backbone network are built by the topology,
> there is a possibility that some nodes/links are over congested, whereas
> other are not.
> 
> 2) If a network wants to provide 2 different kinds of service, for example,
> premium service and best effort. For the premium service tree, the receiver
> may be able to specified the whole reverse path to RP which only contain
> premium capable nodes and links. And for the best effort tree, the receiver
> can join the upstream the same way as PIM-SM today. With the MPLS
> label forwarding, 2 kinds of multicast forwarding services are very easily
> achieved.
> 
> best regards,
> Liwen--
> 
> >
> >
> > Regards
> >
> > Bora Akyol
> > Pluris, http://www.pluris.com
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of Liwen Wu
> > Sent: Tuesday, May 25, 1999 5:53 AM
> > To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: Traffic Engineering for multicast traffic
> >
> > I have a couple of thoughts on multicast traffic engineering which I
> > would
> > like to receive comments on them:
> >
> > -------------------------------------------------------------------
> > Definition and Benefits
> > -------------------------------------------------------------------
> > Multicast traffic engineering means that: a multicast forwarding tree
> > is built through policies and explicited routed tree, instead of
> > topology.
> >
> > Multicast traffic engineering can have similar benefits as unicast
> > traffic
> > engineering. It can be used to achieve efficient  network resource
> > utilization.
> >
> > -------------------------------------------------------------------
> > Methods
> > -------------------------------------------------------------------
> > The multicast traffic engineering trees can be built by expanding the
> > existing protocols. There are 2 categories of protocols:
> >
> > a) Receiver initiated tree setup: this kind of tree can have
> > a large number of receivers and they join and prune quite frequently.
> > PIM-SM protocol can be expanded to build this kind of tree.
> >
> > b) Sender initiated tree setup: this kind of tree  can have
> > limited number of receivers with very rare join and prune action.
> > RSVP protocol can be expanded to build this kind of tree.
> >
> > MPLS label switching can be used to forward multicast traffic down the
> > tree to avoid RPF checking
> >
> > -------------------------------------------------------------------
> > PIM-SM modifications for multicast traffic engineering
> > -------------------------------------------------------------------
> >
> > 1) The JOIN msg can be expanded to carry the explicited routed path
> > towards the RP. A PIM-SM router always sends JOIN/PRUNE towards
> > the upstream (parent)  listed in the explicited routed path.
> >
> > 2) The JOIN msg can be expanded to carry a mpls label allocated by the
> > downstream LSR.
> > It can also carry other contraints, such as color, bandwidth etc.
> >
> > 3) A New msg JOIN-NAK can be sent from upstream(parent) to
> > downstream(child)
> > if the upstream can not satisfy the contraints listed in the JOIN msg.
> >
> > -------------------------------------------------------------------
> > RSVP modification for multicast traffic engineering
> > -------------------------------------------------------------------
> > In addition to the extensions listed in
> > <draft-ietf-mpls-rsvp-lsp-tunnel-02.txt>
> >
> > 1) PATH can be expanded to carry the explicited routed tree.
> > New semantics can be defined to reprensent explicited routed tree.
> >
> > If these ideas are acceptable, I would like to expand them to
> > a internet draft.
> >
> > Thanks,
> > Liwen--