The MPLS WG Archive

[Robert Raszuk <raszuk@cisco.com>]

Hi Seisho,

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

I think both cases for p2mp LSP carrying single and multiple multicast
groups should be supported. Further it would be up to the IGMP report
recepient to make the decision if new LSP needs to be created or if any
of his present LSPs can be extended (for example by changing constrains
in the shared explicit way) to carry new multicast group(s). 

> Considering these situation, we choose both objects for LSP identifier.

If you are planning to use any P2MP LSP for multiple groups pipe how do
you calculate tunnel id ? In other words if all multicast packets will
arrive at the egrees unlabed (PHP) or even labeled (no PHP) are you
assuming another IP lookup/RPF check to send it to receivers ?

In other words maybe at some point just lookup on the LFIB would be in
order and label stack would be the tool ? Just trying to make sure that
forwarding wise egress performance will be doable. Another interesting
point is that there could be cases (transient or permanent) that some
received groups should be filtered on the egress of the P2MP LSP rather
then always forwarding it to the potential receiver. Dropping them based
on the label is much more eficient then processing by CPU and dropping
later ;).

Also considering that LSPs are unidirectional (well at least today in
some implementations :) it would be nice to address explicitely how and
if RPF on egrees should be performed.

Thx,
R.

> Seisho Yasukawa wrote:
> 
> 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.
> >---------------------------------------------------------------