Subject: [lisp] LISP Interworking: Proxy Egress Tunnel Routers

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Fri, 18 Sep 2009 11:12:51 -0700

Way back in San Francisco, at the LISP meeting/BoF, I presented my
thoughts about the status of the Interworking draft.  One of the items
was about a concept that had been talked about in the hallways called
Proxy Egress Tunnel Routers (or PETRs for short).  To be clear, in this
email I'm speaking as an editor of the Interworking draft, rather than
as WG co-chair.

To review, today a LISP ITR does not encapsulate packets when the
destination is a non-LISP site.  This is because the destination is a
routable address and in theory the destination field of the packet is
the only field required to be routable.  However, in the case of an xTR
being on a customer premise router, this requires that the IP protocol
version of the hosts be supported by the access network, and that the
access network not be implicitly filtering the EID source via uRPF or
some similar mechanism.

What I'd like to propose is a Proxy ETR that LISP sites would use to
when encapsulating packets which are destined to non-LISP sites. ITRs
could be statically configured with a 'default' map-cache entry that
would encapsulate to the Proxy ETR.  The PETR could/should be configured
to only decapsulate and forward packets for EID prefixes that the PETR
owner/operator agrees to.

Proxy ETRs would remain independent of Proxy ITRs, while technically
they could be implemented in the same device, they serve different
purposes.  In order to minimize stretch on communications between LISP
and non-LISP sites, its very likely that they should be located in
separate places in the topology.

Below is a very short blurb of some text to foster some discussion about
Proxy Egress Tunnel Routers:

   Proxy Egress Tunnel Routers (PETRs) allow for LISP-NR sites to
   communicate with non-LISP sites in the case where the access network
   does not allow for the LISP-NR site send packets with the source
   address of the site's EID(s).  A PETR is a new network element that
   conceptually acts as an ETR for traffic destined to non-LISP sites.
   This also has the effect of allowing an ITR avoid having to decide
   whether to encapsulate packets or not - it will always encapsulate
   packets.  Packets destined to LISP sites will travel directly to that
   site's ETR, all other packets will be sent to the site's PETR.

   There are two primary reasons why sites would want to utilize a PETR:

   Avoiding strict uRPF failures:  Some provider's access networks
      require the source of the packets emitted to be within the
      addressing scope of the access networks. (see section 9)

   Traversing a different IP Protocol:  A LISP site may want to transmit
      packets to a non-LISP site where the some of the intermediate
      network does not support an IP protocol (v4 or v6).  PETRs can
      allow this LISP site's data to 'hop over' this by utilizing LISP's
      support for mixed protocol encapsulation.

Comments appreciated!

Regards,

-Darrel

---

From: Robin Whittle <[email-masked]>
Date: Sat, 19 Sep 2009 15:11:24 +1000

Short version:  Similarities and differences between LISP PETRs
                and the Translating Tunnel Router in the TTR
                Mobility model.

                What are the scenarios for a LISP node needing a
                PETR?  What sort of network and last mile link
                are these nodes on?  How will the node and PETR
                cope with Path MTU Discovery and lost packets?

Hi Darrel,

>       addressing scope of the access networks. (see section 9)

is a function performed by the TTR (Translating Tunnel Router) in
the TTR Mobility model:

  http://www.firstpr.com.au/ip/ivip/#mobile

The MN (Mobile Node) could be on a global unicast address in some
network which, quite correctly, won't allow egress of packets with a
source address not matching this network.

Also, the MN may be behind one or more layers of NAT.

As with PETR, the TTR is located in a network which allows it to emit
packets with any source address.

Unlike the PETR, the TTR also acts as an ETR for the MN.  The MN may
have multiple such TTRs and therefore multiple such ETRs.

I understand that this concept of LISP nodes in access networks which
therefore need a PETR outside that network (or at least a PETR in the
network which is authorised to emit packets with any source address)
resembles the LISP Mobile arrangement.

AFAIK, you haven't specified the commercial relationship between the
operator of the LISP node and the operator of the PETR which it uses.

Do you plan to have provision for two or more PETRs, for redundancy?

I understand that the concept of a PETR is quite separate from that
of the one or more ETRs a LISP node may be using.  For LISP nodes
which need a PETR, does the LISP node perform its own ETR function?
If so, how does this differ from the LISP Mobile arrangement?

In the TTR model - a TTR always performs the ETR function for a MN.
Whether or not any packets for that MN arrive at that TTR depends on
the mapping.

In the PETR model, I understand the LISP node simply encapsulates
packets to send to the PETR, and that it only does this for packets
which are being sent to non-LISP destinations.  This differs from the
TTR model in that MNs send all outgoing packets to the TTR.

The PETR only receives packets from LISP nodes which are addressed to
non-LISP addresses.  So there is no need for the PETR to contain or
be close to an ITR.

In the TTR model (whether applied to Ivip or LISP), the MN has no
involvement mapping.  It never tunnels packets to anywhere but its
one or more TTRs and it has no concept of some destination addresses
being "normal" and others being on addresses which are mapped by the
core-edge separation system (LISP, Ivip or whatever).  The MN sends
all outgoing packets to its TTR, or to one of its one or more TTRs.

For this reason, the TTR is ideally "close" to the MN, such as 1000
km or less.  The system will still work if the TTR and MN are on
opposite sides of the Earth, but generally, for efficiency and lower
latency, the MN will choose a TTR which is nearby.

I understand that you are proposing the PETR approach for non-mobile
LISP nodes.  I guess this is similar to the PETR proposal which is
part of LISP Mobile.  With non-mobile LISP nodes, you could configure
each node to use a nearby PETR.

The TTR would typically contain, or be close to, an ITR function, but
this is not absolutely required.  If it emitted packets which were
addressed to hosts which were on mapped addresses (RLOC addresses for
LISP, "mapped addresses" for Ivip) then if the TTR had no ITR and was
not near one, then the packets would traverse the DFZ until they were
encapsulated by a PTR (Proxy Tunnel Router, for LISP) or OITRD (Open
ITR in the DFZ, for Ivip).

In LISP, I understand you will be specifying an encapsulation format,
or using one which already exists for these traffic packets being
sent to the PETRs.

In the TTR model, at least for Ivip, I haven't specified exactly how
the MN communicates with the TTR.   Since the MN will only be
communicating with a TTR which accepts this communication, typically
on some authorised commercial basis, there is no absolute need to
standardise exactly how the communication occurs.  One TTR company
might have one way of doing it and another might have a different
approach.  This would require different software in the MN, but
that's OK.  There's plenty of scope for innovation and optimising the
protocols to cope with various types of traffic, types of MN and
types of access network.  Since the MN <--> TTR communication is a
private matter between the two parties, there isn't an absolute need
for the IETF to standardise a single approach.

I propose that the MN establish a two-way encrypted tunnel to the
TTR, which it can do from any address, including behind NAT.  Then,
it is up to the the company which runs the TTRs and defines the
protocols how to handle Path MTU Discovery problems, encryption,
compression, resending lost packets etc.

There could be a single IETF defined set of protocols for all this,
but it is not needed, at least initially, since the MN to TTR
arrangement is a private one.

The TTR behaves to the rest of the core-edge separation network as
firstly an ordinary ETR and secondly as a source of outgoing traffic
packets.  The TTR can include a ITR function, but the TTR simply
behaves as an ETR and perhaps an ITR - so the TTR itself doesn't
require any special provisions in the technical standards for the
core-edge separation system (Ivip, LISP or whatever).

Your second function:

>    Traversing a different IP Protocol:  A LISP site may want to
>       transmit packets to a non-LISP site where the some of the
>       intermediate network does not support an IP protocol (v4 or
>       v6).  PETRs can allow this LISP site's data to 'hop over'
>       this by utilizing LISP's support for mixed protocol
>       encapsulation.

is not part of the current TTR model.

Adding a mixed protocol capability to a core-edge separation scheme
may well be a good idea.  I am concentrating on defining a good
scheme for each protocol in isolation, but mixed protocol operations
should definitely be contemplated well before the systems are finalised.

Can you list the sorts of scenarios in which the LISP node would be
using a PETR?

Must the LISP node be on a global unicast address, or can it be
behind one or more layers of NAT?

Do you expect the LISP node to be connected to the Net via a slow,
expensive and unreliable last mile link such as a wireless mobile
network?  Even if the link is not expensive, high packet loss rates
may require special provisions which were not anticipated in the
original concept of LISP: ITRs and ETRs being at ISP sites with
permanent, fibre-based connections, with ISP networks being
conventionally multihomed with BGP.

How do you plan to cope with PMTUD and packet loss problems between
the LISP node and the PETR?  How does the LISP node ensure that the
PETR is still alive?

As far as I can see, any solution to these two problems would involve
two-way communication between the LISP node and its PETR, rather than
a simple send and forget approach.

These problems may be easier to solve in the TTR model because the MN
creates its own encrypted tunnel, which includes its own packet
acknowledgement retry arrangements and could presumably handle PMTUD
methods by chopping packets down to the PMTU limit discovered for the
tunnel, and reassembling them at the other end of the tunnel, with
the tunnel protocol already supporting resending of lost packets
which contain those fragments.

 - Robin