The MPLS WG Archive

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

Hello Robert,

Thank you for useful comment.

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

I agree with you.
Our current design support both cases.

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

We assume another IP lookup at egress LSR.to send multicast packets
to recivers.
And we don't assume any RPF check because this draft can be
applicable to non-IPmulticast network.


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

Could you clarify above question in more detail ?
We also assume this issue is very important when we implement real
P2MP LSR.

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

I agree that in some case, it is more efficient to filter some group traffic
on the egress.
Using this technique, we can avoid leaf-initiated Join/Leave mechanism
and make IGMP interwork more simple.
But I cannot understand detail architecture of your suggestion,
Could you clarify the meaning of last sentence.
" Dropping them based on the label is ........"


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

Yes, we need some mechanism that address explicitely how and if
RPF on egress should be performed when we consider system implementation.

Thanks,

Seisho

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