The MPLS WG Archive

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

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.txt
>
>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.
>---------------------------------------------------------------