Subject: RE: MPLS and NETLMM (was RE: [netlmm] a couple of high-view questions)

From: "Genadi Velev" <[email-masked]>
Date: Thu, 18 May 2006 19:17:25 +0200

Hi Robert, Vidya,

I think a distinction between transport plane and control/signaling
plane could be beneficial for the understanding. The NETLMM protocol is
for the sake of mobility management (MM) and the messages sent between
AR and LMA are independent of the transport technology - they just have
the IP source and destination address of AR and LMA. I also tend to
think that NETLMM, as MM protocol, should be transparent to the
transport (see below). On the other hand MPLS is the transport
technology between LMA and AR, having its own control plane for setting
up and managing LSPs (LDP or RSVP-TE). The transport itself is done by
labels (which are denoting for the LSPs).

On the discussion of using LSP per MN: I think this would complicate the
network management and slow down the handover. This is because at
handover the MAP needs to first set up a LSP to the new AR. IMHO, there
is one or several LSPs (for different QoS) btw. LMA and a single AR and
the MN's data packets are just sent over the LSP.

On the binding between MN and MPLS label (shim label): I don't believe
that the NETLMM messages have to carry any MPLS related info. It is
sufficient if e.g. the NETLMM update message received at the LMA (sent
by whatever new or old AR) contains the IP address of the new AR. Then
the LMA knows that MN's data packets should be sent to that new AR. How
the packets are transported to that new AR is a matter of the transport
technology: MPLS, GTP, IP-in-IP, GRE etc. If the transport is MPLS, the
LMA has LSP(s) to each AR. If a packet P1 should be sent to AR1 and LMA
has a LSP to AR1 and the MPLS label for this LSP is L1, then the LMA
inserts L1 into the P1 and sends it out. How the mapping btw. AR's IP
address and LSP is done is a (IMHO) implementation matter and is
discussed in MPLS WG. From the MM perspective it is improtant that the
LMA knows the IP address (because we are considering IP network) of the
AR where the MN is located. 

This is just my understanding. 

regards,
Genadi

P.S. Regarding the GTP tunnels in 3GPP -- they are set up not only per
MN, but even per application (or using 3GPP's terminology: per PDP
context). However, they are setup only once when a new application
service is started and the tunnel endpoints are normally not changed
during the MN moves (with some rarely exceptions). 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Roberts Phil-APR042
> Sent: Thursday, May 18, 2006 4:17 PM
> To: Narayanan, Vidya; Vijay Devarapalli; Pekka Savola
> Cc: Petrescu Alexandru-AAP021; James Kempf; [email-masked]
> Subject: RE: MPLS and NETLMM (was RE: [netlmm] a couple of 
> high-view questions) 
> 
> 
> That's not the way I took the earlier discussions.  I thought the
> earlier discussions were to allow the use of MPLS for bearer 
> traffic and
> NETLMM should have hooks in its signaling to make use of MPLS bearers.
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> > Narayanan, Vidya
> > Sent: Wednesday, May 17, 2006 6:59 PM
> > To: Vijay Devarapalli; Pekka Savola
> > Cc: Petrescu Alexandru-AAP021; James Kempf; [email-masked]
> > Subject: MPLS and NETLMM (was RE: [netlmm] a couple of high-view
> > questions)
> > 
> > 
> > All,
> > There has been some discussion lately about the use of MPLS LSPs to
> > carry NETLMM signaling. Traffic engineering has been quoted as a
> reason
> > to do this. I'm trying to understand the vision behind this and what
> > kind of traffic engineering benefits people see this offering.
> > 
> > I agree with Vijay's statement that TE would lead to per-MN LSPs and
> > that isn't exactly scalable.
> > 
> > So, is it just the thought of exploiting the existence of MPLS
> backbones
> > for transport of NETLMM signaling between the AR and MN? 
> Or, are there
> > more reasons behind this?
> > 
> > Thanks,
> > Vidya
> > 

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 19 May 2006 16:03:14 +0200

Hi Genadi,

> the MN's data packets are just sent over the LSP.

Right.

> AR where the MN is located. 

This matches my current view of things, too.

	Henrik

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 19 May 2006 09:14:46 -0700

Genadi,

> the IP source and destination address of AR and LMA.

Then it sounds like your opinion is that the AR would only
ever need to convey its IP address to the LMA; nothing else
such as MPLS labels, etc. - correct?

If anything else would need to be conveyed in some scenarios
(e.g., a non-IP Router ID) then that feature can be accommodated
as long as the requirements are known well enough in advance.

Fred
[email-masked]

---

From: "Genadi Velev" <[email-masked]>
Date: Mon, 22 May 2006 10:34:51 +0200

Hi Fred,

please see inline.

> From: Templin, Fred L [mailto:[email-masked]] 
> Sent: Friday, May 19, 2006 6:15 PM
> To: Genadi Velev; Roberts Phil-APR042; Narayanan, Vidya; 
> [email-masked]; [email-masked]
> high-viewquestions) 

IMO it does not make sense to signal MPLS labels in any *NETLMM
messages*. The MPLS concept is based on the exchange of labels at each
MPLS hop (router). Therefore, the labels has meaning only between 2
neighboring MPLS routers. So, if there are intermediate routers between
LMA and AR, which label would the AR signal to the LMA in the *NETLMM
message*? The MPSL label in the *NETLMM message* won't have any meaning
to the LMA. The signaling of MPLS labels is done by LDP or RSVP-TE.

> as long as the requirements are known well enough in advance.

Well, the AR may signal some "non-IP Router ID" if this would help to
the LMA to unambiguously identify the AR. However, according to the
framework/assumptions of this WG, I think the IP address would
unambiguously identify the AR (and this is independent of the transport
between LMA and AR, i.e. ATM, Frame Relay, MPLS, Ethernet etc.).

I'll hold myself back in sending further emails on this thread, since I
don't believe this discussion contributes anything to the targeted
protocol solution.

Genadi