The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] PHP
Eric> I admit I've never quite understood the role of the L3PID in Eric> RSVP-TE signaling. David> It's so the egress router will know what to do with the packet after David> popping the last label. ... assuming that the bottom label represents the RSVP-TE tunnel, rather than a route of some particular L3 protocol. If you run, say, directed LDP through the RSVP-TE tunnel to assign labels to L3 routes (of various L3 protocols), then you don't need the L3PID, since the bottom label will identify the L3 protocol. David> If you don't provide this (like LDP doesn't) then you must either David> assume everything is IP, or you must use some out-of-band mechanism David> for distributing this information. Either way, it pretty much David> defeats the multiprotocol capabilities of MPLS. It's not that you have to assume that everything is IP, it's just IP gets special treatment; it's the only sort of unlabeled packet that can be put into an RSVP-TE tunnel. Other L3s just need to get labeled first. (Another alternative, if you wanted to put multiple L3s into a single RSVP-TE tunnel, would be to require that L3 packets in the tunnel first get encapsulated in something that provides an L3PID.) David> And why is it so superior to carry the L3 protocol ID in every single David> packet, instead of signaling it once when the LSP is established? Carrying the L3 protocol id in ever packet allows packets of multiple L3 protocols to use a single RSVP-TE tunnel. Signaling the L3PID "once" for each protocol requires multiple RSVP-TE tunnels. As these tunnels create state in the core routers, it seems like a very bad idea to set up an extra RSVP-TE tunnel simply to help with the L3 identification.
|
|