The MPLS WG Archive

[Seisho Yasukawa <yasukawa.seisho@lab.ntt.co.jp>]

Hello JL,

>I agree with you. It is important to well separate mutlicast service
>from P2MP LSP setup /
>modification, as P2MP tree can support non-IP Mcast traffic.
>
>Thus addtional procedures an message exchanges are required on top of
>this architecture to support multicast (S, G) Join/ Leave and to allow
>the sender to hold sufficient information in order to optimise multicast
>FEC on sender nodes.

I agree with you.
I also think we need additional procedures on top of this architecture.

>There are two options :
>         -Use an offline tool for FEC determination and tree computation.
>The leaf node learns   LSP parameters from this tool.
>         -Distributed scenario: Leaf node registers (S, G) to the sender
>that determines which P2MP tunnel must be used, and intiates grafting.
>This requires a new (possibly RSVP) message to support such (S, G)
>registation.  (Note that IGMPv2 raises an additional sender localisation
>issue).

Thank you for useful inputs.

I think we can attain first option by current design.
And I assume second option has a merit in scalability.

So how about using (FEC) information instead of (S,G) information
for this registration ?

I think we can attain non-IP traffic distribution if we use this architecture.
And we want to discuss second option for future extension
because we need some modification to current design.

Regards,

Seisho


>-----Message d'origine-----
>De : Seisho Yasukawa [mailto:yasukawa.seisho@lab.ntt.co.jp]
>Envoye : mardi 28 janvier 2003 13:16
>A : LE ROUX Jean-Louis FTRD/DAC/LAN
>Cc : mpls@UU.NET; LARREUR-HEMON Elodie FTRD/DAC/LAN;
>yasukawa.seisho@lab.ntt.co.jp; akullber@netplane.com;
>DCheng@PolarisNetworks.com; Dimitri.Papadimitriou@alcatel.be;
>mjork@avici.com
>Objet : RE: draft-yasukawa-mpls-rsvp-p2mp-00.txt
>
>
>Hello JL and Elodie,
>
>Thank you for useful comments and suggestions.
>Please find my answers and comments in-line.
>
> >Hi Seisho and all
> >
> >We read your draft with much interest, and consider this is a good
> >approach for multicast MPLS-TE tunnels.
> >
> >We have several comments regarding leaf initiated Joining/pruning
> >procedures, and the interaction with access multicast protocols like
> >IGMP :
> >
> >Why does the Join/ leave messages contain the attributes of the P2MP
> >tunnel (Session, and Sender objects) ?
>
>The reason why these messages contain both objects is that this
>protocol uses both objects to identify P2MP LSP tunnel uniquely.
>And this Join/Leave architecture is consistent with other message
>architecture, like Path/Path(Graft)/Path(Prune) message.
>This protocol prepare same interface to LSP handler (who setup and
>modify LSP) in regard to LSP identification.
>In another word, this protocol assumes that all LSP handler knows
>same tunnel information.
>And we think this is also consistent to conventional P2P RSVP-TE
>idea and architecture.
>
>
> >This requires a mechanism for the Join leaf node to dynamicaly learn
> >these attributes.
>
>Yes, I agree your point.
>
> >To our mind, it could be more relevant to include (S,G) or (*, G),or
> >({S}, {G}) in Join /Leave messages, rather than tunnel parameters. Then
> >the sender would have knowledge of (S, G) localization, and could
> >optimise P2MP utilisation (FEC) based on this information.
>
>I like this kind of approach.
>As you suggested, I also think your proposal could be more relevant
>if a P2MP LSP convey single IP Mcast group traffic.
>One of my concern is what should we do when a P2MP LSP conveys
>multiple IP Mcast group traffic.
>Maybe we can resolve this issue by same mechanism.
>But, I think we need some sophisticated algorithm in sender/leaf node.
>And another concern is what should we de when a P2MP LSP conveys
>non-IP Mcast traffic.
>Considering these situation, we choose both objects for LSP identifier.
>
> >In this scenario, the sender would have to maintain a table indicating
> >the registered (S, G) attached to each leaf node.
> >When a potential leaf node receives an IGMPv3 report message for a new
> >(S, G), it checks if it already receives this (S, G), if no it sends a
> >Join message to the sender node, including the (S, G). Then the sender
> >can either graft an existing P2MP tunnel, or create a new tunnel to
> >reach this leaf node, depending on local optimization criteria.
>
>I like this approach.
>So, if you have any solution to above problems, please teach us your
>solution.
>
>And we think this technology can also applicable to
>P2MP backbone technology for Wireless LAN (hot spot) and CATV network
>in addition to content delivery network which is mentioned in draft.
>Using this technology, we can provide broadcast service
>in these network economically.
>
>We want to discuss service applicability issues with you
>if you have some interest in this issue.
>
>
>Thanks,
>
>Seisho
>
>
> >-----Message d'origine-----
> >De : Seisho Yasukawa [mailto:yasukawa.seisho@lab.ntt.co.jp]
> >Envoye : jeudi 23 janvier 2003 09:45
> >A : 'mpls@UU.NET'
> >Cc : yasukawa.seisho@lab.ntt.co.jp
> >Objet : draft-yasukawa-mpls-rsvp-p2mp-00.txt
> >
> >
> >Hello everyone,
> >
> >Please note that the following draft has been newly posted to MPLS WG.
> >
> >Extended RSVP-TE for Point-to-Multipoint LSP Tunnels
> ><draft-yasukawa-mpls-rsvp-p2mp-00.txt>
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-rsvp-p2mp-00.tx
>t
> >
> >This draft specifies the extension to RSVP-TE signaling protocol
> >in support of MPLS P2MP LSP creation/deletion and Leaf initiated
> >Join/Leave signaling.
> >
> >We think P2MP MPLS technology will become increasingly important
> >with the dissemination of new, real-time application, such as content
> >delivery services and video conference, which require P2MP real-time
> >transmission capability with much more bandwidth and stricter QoS
> >control mechanism than conventional IP application.
> >
> >We NTT as a service provider really needs this kind of P2MP MPLS
> >technology because this technology opens the possibility to offer
> >our customer a new broadband service.
> >
> >We think discussion of P2MP technology agrees with the charter of this
> >wg.
> >And, we found that applications of "multicast explicit routing"are a
> >target
> >topic for "RSVP-TE "(RFC3209, Section 4.3.1) and "IP Multicast in a
>MPLS
> >Environment"(RFC3353, Section.7)
> >
> >Therefore, we want to discuss this P2MP MPLS technology in this wg.
> >
> >Please give us any comments from technology, application and operation
> >sides.
> >
> >We need a lot of discussion and advice for protocol architecture to
> >improve
> >this architecture.
> >
> >
> >Thanks
> >
> >Seisho
> >
> >------------------------------------------------------------
> >Please refere followings (contents of this draft).
> >
> >This draft include the contents of "draft-yasukawa-mpls-rsvp-p2mp-01".
> >In this new draft, protocol architecture is modified and the protocol
> >name
> >was changed from "multicast" to "P2MP" to clarify the technology
> >difference.
> >
> >Section 0 describes why this draft suit to this wg.
> >Please see sec.0.4 to know the reason why we introduce P2MP tunnel
> >without IP multicast.
> >
> >Section 4 describes the architecture of this protocol.
> >The new concepts; P2MP LSP tunnel and TERO/TRRO are newly introduced.
> >The TERO is main architecture to realize P2MP TE LSP.
> >
> >Section 5 - 7 describes the detailed signaling mechanisms.
> >
> >Section 11 shows the difference between RSVP multicasting and P2MP
> >TE tunnels.
> >
> >We describe the difference between multicast LSP realized by
> >RSVP-TE&IP multicasting and P2MP TE LSP realized by TERO.
> >---------------------------------------------------------------