The MPLS WG Archive

["LE ROUX Jean-Louis FTRD/DAC/LAN" <jeanlouis.leroux@rd.francetelecom.com>]

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) ? 
This requires a mechanism for the Join leaf node to dynamicaly learn
these attributes.

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.

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.

Regards

JL and Elodie



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