The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Jan> msg00111



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

draft-yasukawa-mpls-rsvp-p2mp-00.txt

  • From: Loa Andersson <loa@pi.se>
  • Date: Thu, 23 Jan 2003 20:08:10 +0100
  • CC: "'mpls@UU.NET'" <mpls@UU.NET>
  • User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
  • X-Original-Recipient: mpls@UU.NET

All,

I've received a couple of questions if this is a working group draft.
Answer is that it is not, a previous draft was presented in Atlanta
and (I think in Yokohama), the name change makes it go back to -00.
In Atlanta we said that "the discusion will contiune on the list".

Possibly the misunderstanding comes from the first line in
the mail:
"Please note that the following draft has been newly posted to MPLS WG."

my understanding here is that this a request from the authors to
have comments on the draft and discusion on the subject matter.

/Loa


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


-- 
Loa Andersson

Mobile          +46 739 81 21 64
Email           loa@pi.se