Subject: FW: Questions on your white paper

From: Ben Miller <[email-masked]>
Date: Thu, 19 Apr 2001 11:13:40 +0100

Rae
 
I have interleaved some answers to your questions on our white paper below.
 
Ben

----------------------------------------------- 
Ben Miller 
Business Unit Manager, Network Convergence Group 
Data Connection Ltd 
Tel:  +44 (0) 20 8366 1177      Fax:  +44 (0) 20 8363 1468 
Email:  [email-masked]  Web:  http://www.dat <http://www.dat/>
aconnection.com 

-----Original Message-----
From: Rae M. Chang [mailto:[email-masked]]
Sent: Wednesday, April 18, 2001 9:21 AM
To: Ben Miller
Subject: Questions on your white paper

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.  <mailto:[email-masked]> [email-masked] 
  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
-------------------------------------------------