Subject: Re: Traffic Engineering for multicast traffic

From: Anindo Banerjea <[email-masked]>
Date: Tue, 25 May 1999 11:27:58 -0700 (PDT)

Here is a link to the Faloutsos et al paper.

http://www.isi.edu/~banerjea/research/qosmic.ps

There is also a more recent simulation paper showing the increase
in the number of supportable applications for different QoS requirements
for QoSMIC vs. PIM.

http://www.isi.edu/~banerjea/research/rtaw99.pdf

Anindo

> From [email-masked] Tue May 25 08:50:03 1999
> To: Liwen Wu <[email-masked]>
> cc: [email-masked], [email-masked], [email-masked], [email-masked]
> Subject: Re: Traffic Engineering for multicast traffic
> Date: Tue, 25 May 1999 16:48:49 +0100
> From: Jon Crowcroft <[email-masked]>
> X-Status: 
> 
> 
> In message <[email-masked]>, Liwen Wu typed:
> 
> 
> there is already a small bodyo of work on QoS multicast routing which
> invovles some of these options - check out papers in ACM CCR by
> Carlberg, and papers in SIGCOMM and elsewhere by Faloutsos et al - see
> http://www.acm.org/sigcomm/sigcomm98/tp/abs_12.html
> for a link...
> 
>  >>-------------------------------------------------------------------
>  >>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--
>  >>
>  >>
>  >>
>  >>
>  >>--------------4971525D2938989A0185079B
>  >>Content-Type: text/x-vcard; charset=us-ascii;
>  >> name="liwen.wu.vcf"
>  >>Content-Transfer-Encoding: 7bit
>  >>Content-Description: Card for Liwen Wu
>  >>Content-Disposition: attachment;
>  >> filename="liwen.wu.vcf"
>  >>
>  >>begin:vcard 
>  >>n:Wu;Liwen
>  >>tel;fax:703-724-2003
>  >>tel;work:703-724-2619
>  >>x-mozilla-html:FALSE
>  >>org:Alcatel;R&D
>  >>version:2.1
>  >>email;internet:[email-masked]
>  >>adr;quoted-printable:;;44983 Knoll Square=0D=0A;Ashburn;VA;20147;U.S.A
>  >>x-mozilla-cpt:;18304
>  >>fn:Liwen Wu
>  >>end:vcard
>  >>
>  >>--------------4971525D2938989A0185079B--
>  >>
> 
>  cheers
> 
>    jon
> 
>

---

From: Anindo Banerjea <[email-masked]>
Date: Tue, 25 May 1999 14:33:27 -0700 (PDT)

See

for one solution to this
problems of needing to keep explicit topology of the entire tree.

Anindo