The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Hierarchical Tunnel Establishment in RSVP-TE
Curtis, The PHP options brings up a question that I've asked a long time ago, but went un-answered: Are "inner" labels restricted to be from the "platform" label pool ? Are there implementations that use "per-interface" label pools to allocate inner labels ? It is concivable that an implementation will choose to define an LSP (or set of them) as an interface. And, on top of this interface manage a "per-interface" label pool. This can help simplify routing for example. If this is allowed, then the PHP solution will break, since only the outer label identifys the incomming "interface". Andi. >-----Original Message----- >From: Curtis Villamizar [mailto:curtis@avici.com] >Sent: Tuesday, June 13, 2000 10:16 AM >To: Kireeti Kompella >Cc: curtis@avici.com; mpls@UU.NET >Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE > > > >In message <200006130658.XAA20801@kummer.juniper.net>, Kireeti >Kompella writes: >> > Two POPs are needed to terminate a VPN tunnel. >> >> Not if you use PHP. You start popping one hop earlier, e.g., if >> X is the PE attached to the customer, and Y the penultimate hop, >> Y pops the "outer label" and forwards the packet with the "inner >> label" identifying the VPN to X. X looks at the inner (only!) >> label, pops it and knows which customer to forward the packet to. >> >> Corner case: a one-hop LSP carrying VPN info: don't put any "outer >> label" in this case. >> >> > Three might be needed >> > if the outer tunnel on the VPN took its last hop through a FA-PSC. >> >> Picture time: >> >> A ---- B ==== C ==== D ==== E ~~~~ customer >> <-43- <-28- <--3- >> <--71-- <-------- 3 ------- >> >> <-- 32 for VPN to customer -- >> >> There's an FA-LSP from B to E. E sends D an implicit NULL label, >> D sends C label 28, C sends B 43. >> >> Now, there's another LSP that wants to tunnel through the above >> FA-LSP. This LSP has 2 hops, A->B and B->E. E sends B label 3, >> B sends A label 71. >> >> A and E agree on label 32 for the VPN. >> >> The label stack for a packet to the customer is as follows: >> >> A ---- B ==== C ==== D ==== E ~~~~ customer >> 43 28 >> 71 >> 32 32 32 32 >> >> Note that 71 -> 43 is not really a swap as much as a pop (PHP), >> followed by a push (equivalent, but you get there differently). >> >> It is interesting to first work out the case where the tunneled >> LSP terminates beyond the tail of the FA-LSP, as the above example >> is another 'corner case'. >> >> Kireeti. > > >Kireeti, > >PHP does remove POPs and make it easier to implement an egress LSR but >it makes it very hard to collect statistics of packets and bytes >received on an LSP at the egress. Recall the discussion of OAM and >loss measurements. There is no way to count at the egress if the >labels are lost. Therefore in your example there is no way to >determine loss over the FA-PSC tunnel or over the tunnel from A-E. > >Curtis >
|
|