SUtoSU Packet Data Routing

1
SU-to-SU Packet Data Routing

• Todd Leigh, Motorola Inc.
• submitted to PSAWG
• 10-6-06

2
SU-to-SU Packet Data Routing

• The question is, how should SU-to-SU packet data
  be routed? Is it necessary
• to route it through the customer
• network,
• or internal to the radio network
• (over the ISSI if the SUs have
• different Home RFSSs),
• bypassing the customer
• network,
• or are both options needed?
• Note that only SUs using the same APN can route
  packet data to each other, as an IP address plan
  is only valid within a single APN.

3
ISSI Routing

• In ISSI routing, the ISSI is used to route SU-to-
• SU packet data over an IP tunnel on the ISSI.

A binding must be maintained in every RFSS
between every IP address assigned to any mobile
entity in the network and the IP address of its
Home RFSS. This becomes a big problem with
large numbers of SUs or RFSSs, and if the
bindings have to change .

• Advantages
• cant think of any

• Disadvantages
• Requires maintenance of
• a large routing table
• Requires additions to
• ISSI specification
• Bypasses customer
• monitoring firewalls

4
Customer Network Routing
In Customer Network Routing, the routing
mechanism in the customer network handles routing
the IP packets

• Disadvantages
• cant think of any

• Advantages
• Requires no additional
• routing information
• Requires no additions to
• ISSI specification
• Does not bypass
• customer monitoring
• firewalls

5
Motorola Recommendations

• We propose that the network only support Customer
  Network routing for SU-to-SU packet data, and
  that ISSI routing not be supported.
• If some justification for ISSI routing can be
  found, we propose that ISSI routing be a Standard
  Option, and Customer Network routing be Mandatory.

6
Backup

• The main disadvantage of the ISSI routing idea is
  that every RFSS needs to maintain a binding
  between every IP address assigned to any mobile
  entity (MRC or MDP) in the network and the IP
  address of the Home RFSS for that mobile entity.
  The slide that follows provide support for the
  fact that, without this binding, it is impossible
  to route SU-to-SU packet data over the ISSI.
• There dont seem to be any benefits to routing
  over the ISSI, and there are other disadvantages
  too, not the least of which is that it adds more
  work to the definition of the ISSI. The last
  slide captures some dubious benefits that we may
  want to argue about.

7
This binding is established by Mobile IP
registration.
DA10.1.1.2
SA10.1.1.1
DA10.1.1.2
SA10.1.1.1
DA192.168.2.1
SA192.168.1.1
Visited RFSS for SU 1 192.168.1.1
Home RFSS for SU 1 192.168.2.1
So how does RFSS 2 know that 10.1.1.2 has Home
RFSS 3?
10.1.1.1
RFSS 1
RFSS 2
SU1
DA10.1.1.2
SA10.1.1.1
DA192.168.3.1
SA192.168.2.1
RFSS 4
RFSS 3
SU2
10.1.1.2
Visited RFSS for SU 2 192.168.4.1
Home RFSS for SU 2 192.168.3.1
This binding is established by Mobile IP
registration.
DA10.1.1.2
SA10.1.1.1
DA10.1.1.2
SA10.1.1.1
DA192.168.4.1
SA192.168.3.1
8
ISSI routing benefits

• Security
• If you have to de-crypt a packet (say, to find
  the destination IP address) in the CN, youd also
  have to de-crypt in the RFSS for the same reason
• Key management is it a problem to provide a key
  to an entity in the CN, which might force you to
  decrypt in the RFSS before routing to the CN? If
  so, end-to-end to a FES is going to be a problem.
• Note that the method for doing end-to-end
  encryption of packet data isnt defined yet
• If the RFSSs and SUs are in the same IP address
  realm, it might be possible to do this without a
  big routing nightmare
• If theres a small system, routing might not be a
  big problem
• If theres no CN (only SU-to-SU packet data) this
  might be worth doing.