Hello,
I've read your white paper, titled "MPLS TE: A Choice of
Signaling Protocols" and
have some wonders what you really mean.
1) In section 5.2 Security:
you wrote, "RSVP targets its PATH messages at the egress LSR
so that the
intermediate LSRs cannot access the PATH messages. (in case
of IPSEC applied)"
But, isn't it true that the IP packets including the PATH
message have to be addressed
to peer LSR node across the to-be LSP
route?
I can't understand why the PATH message has to be targeted
at the egress LSR
when you encapsulate the PATH message with
IPSEC.
IPSEC relies on tokens known to the
endpoints. Traditional
RSVP (and therefore RSVP-TE for MPLS) requires
that the destination for the
PATH is the egress of the LSP. In order
for intermediate nodes to
spot the PATH message, the RouterAlert bit is set, informing intermediate
nodes that they should check the contents of the packet. On seeing that
it is an RSVP message, the intermediate node knows it should pass it to
the RSVP/MPLS stack for processing. The intermediate nodes do not have
the IPSEC tokens for the endpoints, and therefore they could not decode a PATH that the ingress had encrypted using the egress IPSEC token. Hence, IPSEC cannot be used
for these packets.
However, there
is more to this story.
Because some
devices may not understand the RouterAlert bit, the RSVP spec effectively
allows the PATH messages to be sent to the next hop. Although this is
not 100% spec compliant, it is expected to work in most cases. (The
intermediate nodes then learn the LSP destination from the Explicit Route
Object.) If this processing were used, IPSEC could be used between each
hop.
Furthermore, the GMPLS
extensions that require/allow out-of-band signalling introduce another
option. When running GMPLS with out-of-band signalling, it is
possible (and sometimes necessary) to address the RSVP packets to intermediate
nodes. This would be the case if, for example, a network of optical
cross-connects is exchanging signalling data by sending RSVP messages over the
Internet. In this case, sending RSVP packets to the LSP destination and
setting the RouterAlert bit would mean that every router in the Internet
attempted to process the packet, whereas you only want the optical
cross-connects on the path to do so.
GMPLS
therefore allows the RSVP packets to be encapsulated within another IP
header. The RSVP packet will be addressed to the LSP destination, but
the outer IP packet will be addressed to the next hop on that path. The
Internet will then forward the double encapsulated packet to the next
hop. If this method were used, the nodes on the path could use
IPSEC.
2) In section 5.13 Layer 3 Protocol:
you wrote, "RSVP identifies a single payload protocol during
LSP setup, but there is
no scope within the protocol for CR-LDP to do
this."
I'm still trying to understand what you really
meant. Do you mean that:
with RSVP, you can only setup an LSP for the usage of a
single layer 3 protocol, and
with CR-LDP, you can use one LSP route for transmitting any
number of layer 3 protocols?
It may be useful for egress
LSR to know the layer 3 protocol. RSVP allows this (but only one L3
protocol per LSP). CR-LDP does not have this facility at
all. In both cases,
the nodes on the path can ignore the L3 protocol.
More clear explanation can help me understand your paper.
And if I have to read the other
resources, could you
please point those? Your help will be very
appreciated.
Thanks for your nice paper, again.
Regards,
Rae
-------------------------------------------------
Myong-Rae Chang, Ph.D. cmr@sktelecom.com
4G R&D Team,
SK Telecom R&D Center
9-1 Sunae-dong Pundang-gu Sungnam City
Kyunggi-do 463-020, South Korea
Mobile:
+82-11-9874-3926
TEL +82-342-710-5201 FAX
+82-31-710-5299
-------------------------------------------------