Internet DRAFT - draft-ietf-netext-logical-interface-support
draft-ietf-netext-logical-interface-support
NETEXT WG T. Melia, Ed.
Internet-Draft Kudelski Security
Intended status: Informational S. Gundavelli, Ed.
Expires: September 14, 2016 Cisco
March 13, 2016
Logical-interface Support for Multi-access enabled IP Hosts
draft-ietf-netext-logical-interface-support-14
Abstract
A Logical-interface is a software semantic internal to the host
operating system. This semantic is available in all popular
operating systems and is used in various protocol implementations.
The Logical-interface support is required on the mobile node attached
to a Proxy Mobile IPv6 domain, for leveraging various network-based
mobility management features such as inter-technology handoffs,
multihoming and flow mobility support. This document explains the
operational details of Logical-interface construct and the specifics
on how the link-layer implementations hide the physical interfaces
from the IP stack and from the network nodes on the attached access
networks. Furthermore, this document identifies the applicability of
this approach to various link-layer technologies and analyzes the
issues around it when used in conjunction with various mobility
management features.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
Melia & Gundavelli Expires September 14, 2016 [Page 1]
Internet-Draft Logical Interface Support March 2016
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Hiding Link-layer Technologies - Approaches and
Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Link-layer Abstraction - Approaches . . . . . . . . . . . 5
3.2. Link layer support . . . . . . . . . . . . . . . . . . . . 6
3.3. Logical Interface . . . . . . . . . . . . . . . . . . . . 6
4. Technology Use cases . . . . . . . . . . . . . . . . . . . . . 7
5. Logical Interface Functional Details . . . . . . . . . . . . . 8
5.1. Configuration of a Logical Interface . . . . . . . . . . . 9
5.2. Logical-Interface Forwarding Table . . . . . . . . . . . . 9
6. Logical Interface Use-cases in Proxy Mobile IPv6 . . . . . . . 11
6.1. Multihoming Support . . . . . . . . . . . . . . . . . . . 11
6.2. Inter-Technology Handoff Support . . . . . . . . . . . . . 12
6.3. Flow Mobility Support . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Melia & Gundavelli Expires September 14, 2016 [Page 2]
Internet-Draft Logical Interface Support March 2016
1. Introduction
Proxy Mobile IPv6 (PMIPv6) [RFC5213] is a network-based mobility
management protocol standardized by IETF. One of the key goals of
the PMIPv6 protocol is to enable a mobile node to perform handovers
across access-networks based on different access technologies. The
protocol was also designed with the goal to allow a mobile node to
simultaneously attach to different access networks and perform flow-
based access selection [I-D.ietf-netext-pmipv6-flowmob]. The base
protocol features specified in [RFC5213] and [RFC5844] has support
for these capabilities. However, for supporting these features, the
mobile node is required to be enabled with with specific software
configuration known as logical-interface support. The logical-
interface configuration is essential for a mobile node to perform
inter-access handovers without impacting the IP sessions on the host.
A Logical Interface construct is internal to the operating system.
It is an approach of interface abstraction, where a logical link-
layer implementation hides a variety of physical interfaces from the
IP stack. This semantic was used on a variety of operating systems
to implement applications such as Mobile IP client [RFC6275] and
IPsec VPN client [RFC4301]. Many host operating systems have support
for some form of such logical interface construct. But, there is no
specification which documents the behavior of these logical-
interface, or the requirements of a logical interface for supporting
the above mentioned mobility management features. This specification
attempts to document these aspects.
The rest of the document provides a functional description of a
Logical Interface on the mobile node and the interworking between a
mobile node using a logical interface and the network elements in the
Proxy Mobile IPv6 domain. It also analyzes the issues involved with
the use of logical-interface and characterizes the contexts in which
such usage is appropriate.
Melia & Gundavelli Expires September 14, 2016 [Page 3]
Internet-Draft Logical Interface Support March 2016
2. Terminology
All the mobility related terms used in this document are to be
interpreted as defined in Proxy Mobile IPv6 specifications, [RFC5213]
and [RFC5844]. In addition, this document uses the following terms:
PIF (Physical Interface) - It is a network interface module on the
host that is used for connecting to an access network. An host
typically has number of network interface modules, such as
Ethernet, Wireless LAN, LTE ..etc. Each of these network
interfaces can support specific link technology.
LIF (Logical Interface) - It is a virtual interface in the IP stack.
Logical interface appears to the IP stack just as any other
physical interface, provides similar semantics with respect to
packet transmit and receive functions to the upper layers of the
IP stack. However, it is only a logical construct and is not a
representation of an instance of any physical hardware.
SIF (Sub Interface) - It is a physical or logical interface that is
part of a logical interface construct. For example, a logical
interface may have been created abstracting two physical
interfaces, LTE and WLAN. These physical interfaces, LTE and WLAN
are referred to as sub-interfaces of that logical interface. In
some cases, a sub-interface can also be another logical interface,
such as an IPsec tunnel interface.
Melia & Gundavelli Expires September 14, 2016 [Page 4]
Internet-Draft Logical Interface Support March 2016
3. Hiding Link-layer Technologies - Approaches and Applicability
There are several techniques that allow hiding of changes in access-
technology changes from the host layer. These changes in access
technology is primarily due to host's movement between access
networks. This section classifies these existing techniques into a
set of generic approaches, according to their most representative
characteristics. Later sections of this document analyze the
applicability of these solution approaches for supporting features
such as, inter-technology handovers and IP flow mobility support for
a mobile node.
3.1. Link-layer Abstraction - Approaches
The following generic mechanisms can hide access technology changes
from host IP layer:
o Link-layer Support - Certain link-layer technologies are able to
hide physical media changes from the upper layers. For example,
IEEE 802.11 is able to seamlessly change between IEEE 802.11a/b/g
physical layers. Also, an 802.11 STA can move between different
Access Points within the same domain without the IP stack being
aware of the movement. In this case, the IEEE 802.11 MAC layer
takes care of the mobility, making the media change invisible to
the upper layers. Another example is IEEE 802.3, that supports
changing the rate from 10Mbps to 100Mbps and to 1000Mbps. Another
example is the situation in the 3GPP Evolved Packet System
[TS23401] where a UE can perform inter-access handovers between
three different access technologies (2G GERAN, 3G UTRAN, and 4G
E-UTRAN) that are invisible to the IP layer at the UE.
o A logical interface denotes a mechanism that logically groups
several physical interfaces so they appear to the IP layer as a
single interface (see Figure 1). Depending on the type of access
technologies, it might be possible to use more than one physical
interface at a time -- such that the node is simultaneously
attached via different access technologies -- or just to perform
handovers across a variety of physical interfaces. Controlling
the way the different access technologies are used (simultaneous,
sequential attachment, etc) is not trivial and requires additional
intelligence and/or configuration within the logical interface
implementation. The configuration is typically handled via a
connection manager, and based on a combination of user preferences
on one hand, and operator preferences such as those provisioned by
the Access Network Discovery and Selection Function (ANDSF)
[TS23402] on the other hand. The IETF Interfaces MIB specified in
[RFC2863] and the YANG data model for Interface management
specified in [RFC7223] treats logical interface as just any other
Melia & Gundavelli Expires September 14, 2016 [Page 5]
Internet-Draft Logical Interface Support March 2016
type of network interface on the host. This essentially makes
logical interface as a natural operating system construct.
3.2. Link layer support
Link layer mobility support applies to cases when the same link layer
technology is used and mobility can be fully handled at that layer.
One example is the case where several 802.11 access points are
deployed in the same subnet with a common IP layer configuration
(DHCP server, default router, etc.). In this case the handover
across access points need not to be hidden to the IP layer since the
IP layer configuration remains the same after a handover. This type
of scenario is applicable to cases when the different points of
attachment (i.e. access points) belong to the same network domain,
e.g. Enterprise, hotspots from same operator, etc.
Since this type of link layer technology does not typically allow for
simultaneous attachment to different access networks of the same
technology, the logical interface would not be used to provide
simultaneous access for purposes of multihoming or flow mobility.
Instead, the logical interface can be used to provide inter-access
technology handover between this type of link layer technology and
another link layer technology, e.g., between IEEE 802.11 and IEEE
802.16.
3.3. Logical Interface
The use of a logical interface allows the mobile node to provide a
single interface perspective to the IP layer and its upper layers
(transport and application). Doing so allows to hide inter-access
technology handovers or application flow handovers across different
physical interfaces.
The logical interface may support simultaneous attachment, in
addition to sequential attachment. It requires additional support at
the node and the network in order to benefit from simultaneous
attachment. For example special mechanisms are required to enable
addressing a particular interface from the network (e.g. for flow
mobility). In particular extensions to PMIPv6 are required in order
to enable the network (i.e., the MAG and LMA) to deal with logical
interface, instead to IP interfaces as current RFC5213 does. RFC5213
assumes that each physical interface capable of attaching to a MAG is
an IP interface, while the logical interface solution groups several
physical interfaces under the same IP logical interface.
It is therefore clear that the Logical Interface approach satisfies
the multi technology and the sequential vs: simultaneous access
support.
Melia & Gundavelli Expires September 14, 2016 [Page 6]
Internet-Draft Logical Interface Support March 2016
4. Technology Use cases
3GPP has defined the Evolved Packet System (EPS) for heterogeneous
wireless access. A mobile device equipped with 3GPP and non-3GPP
wireless technologies can simultaneously or sequentially connect any
of the available devices and receive IP services through any of them.
This document focuses on employing a logical interface for
simultaneous and sequential use of a variety of access technologies.
As mentioned in the previous sections the Logical Interface construct
is able to hide to the IP layer the specifics of each technology in
the context of network based mobility (e.g. in multi-access
technology networks based on PMIPv6). The LIF concept can be used
with at least the following technologies: 3GPP access technologies
(3G, LTE), IEEE 802.16 access technology, and IEEE 802.11 access
technology.
In some UE implementations the wireless connection setup is based on
creation of a PPP interface between the IP layer and the wireless
modem that is configured with the IPCP and IPv6CP protocol [RFC5072].
In this case the PPP interface does not have any L2 address assigned.
In some other implementations the wireless modem is presented to the
IP layer as a virtual Ethernet interface.
Melia & Gundavelli Expires September 14, 2016 [Page 7]
Internet-Draft Logical Interface Support March 2016
5. Logical Interface Functional Details
This section identifies the functional details of a logical interface
and provides some implementation considerations.
On most operating systems, a network interface is associated with a
physical device that offers the services for transmitting and
receiving IP packets from the network. In some configurations, a
network interface can also be implemented as a logical interface
which does not have the inherent capability to transmit, or receive
packets on a physical medium, but relies on other physical interfaces
for such services. Example of such configuration is an IP tunnel
interface.
An overview of a logical interface is shown in Figure 1. The logical
interface allows heterogeneous attachment while making changes in the
underlying media transparent to the IP stack. Simultaneous and
sequential network attachment procedures are therefore possible,
enabling inter-technology and flow mobility scenarios.
+----------------------------+
| TCP/UDP |
Session to IP +---->| |
Address binding | +----------------------------+
+---->| IP |
IP Address +---->| |
binding | +----------------------------+
+---->| Logical Interface |
Logical to +---->| IPv4/IPv6 Address |
Physical | +----------------------------+
Interface +---->| L2 | L2 | | L2 |
binding |(IF#1)|(IF#2)| ..... |(IF#n)|
+------+------+ +------+
| L1 | L1 | | L1 |
| | | | |
+------+------+ +------+
Figure 1: General overview of logical interface
From the perspective of the IP stack and the applications, a Logical
interface is just another interface. In fact, the logical interface
is only visible to the IP and upper layers when enabled. A host does
not see any operational difference between a Logical and a physical
interface. As with physical interfaces, a Logical interface is
represented as a software object to which IP address configuration is
bound. However, the Logical interface has some special properties
which are essential for enabling inter-technology handover and flow-
mobility features. Following are those properties:
Melia & Gundavelli Expires September 14, 2016 [Page 8]
Internet-Draft Logical Interface Support March 2016
1. The logical interface has a relation to a set of physical
interfaces (sub-interfaces) on the host that it is abstracting.
These sub-interfaces can be attached or detached from the Logical
Interface at any time. The sub-interfaces attached to a Logical
interface are not visible to the IP and upper layers.
2. The logical interface may be attached to multiple access
technologies.
3. The Transmit/Receive functions of the logical interface are
mapped to the Transmit/Receive services exposed by the sub-
interfaces. This mapping is dynamic and any change is not
visible to the upper layers of the IP stack.
4. The logical interface maintains IP flow information for each of
its sub-interfaces. A conceptual data structure is maintained
for this purpose. The host may populate this information based
on tracking each of the sub-interface for the active flows.
5.1. Configuration of a Logical Interface
A host may be statically configured with the logical interface
configuration, or an application such as a connection manager on the
host may dynamically create it. Furthermore, the set of sub-
interfaces that are part of a logical interface construct may be a
fixed set, or may be kept dynamic, with the sub-interfaces getting
added or deleted as needed. The specific details related to these
configuration aspects are implementation specific and are outside the
scope of this document.
The IP layer should be configured with a default router reachable via
the logical interface. The default router can be internal to the
logical interface, i.e., it is a logical router that in turns decide
which physical interface is to be used to transmit packets.
5.2. Logical-Interface Forwarding Table
The logical interface maintains the list of sub-interfaces that are
part of logical-interface construct. This is a conceptual data
structure, called as the Logical-Interface Forwarding Table.
The logical interface also maintains the list of flows associated
with a given sub-interface and this conceptual data structure is
called as the PIF Table. Both of these data structures have to be
associated with a logical interface, and are depicted in Figure 2.
Melia & Gundavelli Expires September 14, 2016 [Page 9]
Internet-Draft Logical Interface Support March 2016
LIF TABLE FLOW table
+===============================+ +=============================+
| PIF_ID | FLOW Routing Policies| | FLOW ID | Physical_Intf_Id |
| | Link Status | +-----------------------------+
+-------------------------------| | FLOW_ID | Physical_Intf_Id |
| PIF_ID | FLOW Routing Policies| +=============================+
| | Link Status | + .... | .... |
+-------------------------------+ +=============================+
| .... | .... |
+===============================+
Figure 2: Logical Interface Table
The LIF table maintains the mapping between the LIF and each PIF
associated to the LIF (refer to property #3, Figure 1). For each PIF
entry the table should store the associated Routing Policies, and the
Link Status of the PIF (e.g. active, not active). The method by
which the Routing Policies are configured on the host is out of scope
for this document.
The FLOW table allows the logical interface to properly route each IP
flow over the right interface. The logical interface can identify
the flows arriving on its sub-interfaces and associate them to those
sub-interfaces. This approach is similar to reflective QoS performed
by the IP routers. For locally generated traffic (e.g. unicast
flows), the logical interface should perform interface selection
based on the Flow Routing Policies. In case traffic of an existing
flow is suddenly received from the network on a different sub-
interface than the one locally stored, the logical interface should
interpret the event as an explicit flow mobility trigger from the
network and it should update the PIF_ID parameter in the FLOW table.
Similarly, locally generated events from the sub-interfaces, or
configuration updates to the local policy rules can cause updates to
the table and hence trigger flow mobility.
Melia & Gundavelli Expires September 14, 2016 [Page 10]
Internet-Draft Logical Interface Support March 2016
6. Logical Interface Use-cases in Proxy Mobile IPv6
This section explains how the Logical interface support on the mobile
node can be used for enabling some of the Proxy Mobile IPv6 protocol
features.
6.1. Multihoming Support
A mobile node with multiple interfaces can attach simultaneously to
the Proxy Mobile IPv6 domain. If the host is configured to use
Logical interface over the physical interfaces through which it is
attached, following are the related considerations.
LMA Binding Table
+========================+
+----+ | HNP MN-ID CoA ATT |
|LMA | +========================+
+----+ | HNP-1 MN-1 PCoA-1 5 |
//\\ | HNP-1 MN-1 PCoA-2 4 |
+---------//--\\-----------+
( // \\ )
( // \\ )
+------//--------\\--------+
// \\
PCoA-1 // \\ PCoA-2
+----+ +----+
(WLAN) |MAG1| |MAG2| (3GPP)
+----+ +----+
\ /
\ /
\ /
\ /
\ /
+-------+ +-------+
| if_1 | | if_2 |
|(WLAN) | |(3GPP) |
+-------+-+-------+
| Logical |
| Interface |
| (HNP-1) |
+-----------------|
| MN |
+-----------------+
Figure 3: Multihoming Support
Melia & Gundavelli Expires September 14, 2016 [Page 11]
Internet-Draft Logical Interface Support March 2016
6.2. Inter-Technology Handoff Support
The Proxy Mobile IPv6 protocol enables a mobile node with multiple
network interfaces to move between access technologies, but still
retaining the same address configuration on its attached interface.
The protocol enables a mobile node to achieve address continuity
during handoffs. If the host is configured to use Logical interface
over the physical interface through which it is attached, following
are the related considerations.
LMA's Binding Table
+==========================+
+----+ | HNP MN-ID CoA ATT |
|LMA | +==========================+
+----+ | HNP-1 MN-1 PCoA-1 5 |
//\\ (pCoA-2)(4) <--change
+---------//--\\-----------+
( // \\ )
( // \\ )
+------//--------\\--------+
// \\
PCoA-1 // \\ PCoA-2
+----+ +----+
(WLAN) |MAG1| |MAG2| (3GPP)
+----+ +----+
\ /
\ Handoff /
\ /
\ /
+-------+ +-------+
| if_1 | | if_2 |
|(WLAN) | |(3GPP) |
+-------+-+-------+
| Logical |
| Interface |
| (HNP-1) |
+-----------------|
| MN |
+-----------------+
Figure 4: Inter-Technology Handoff Support
o When the mobile node performs an handoff between if_1 and if_2,
the change will not be visible to the applications of the mobile
node.
Melia & Gundavelli Expires September 14, 2016 [Page 12]
Internet-Draft Logical Interface Support March 2016
o The protocol signaling between the network elements will ensure
the local mobility anchor will switch the forwarding for the
advertised prefix set from MAG1 to MAG2.
6.3. Flow Mobility Support
For supporting IP flow mobility, there is a need to support vertical
handoff scenarios such as transferring a subset of prefix(es) (hence
the flows associated to it/them) from one interface to another. The
mobile node can support this scenario by using the Logical interface
support. This scenario is similar to the Inter- technology handoff
scenario defined in Section 6.2, only a subset of the prefixes are
moved between interfaces.
Additionally, IP flow mobility in general initiates when the LMA
decides to move a particular flow from its default path to a
different one. The LMA can decide on which is the best MAG that
should be used to forward a particular flow when the flow is
initiated e.g. based on application policy profiles) and/or during
the lifetime of the flow upon receiving a network-based or a mobile-
based trigger. However, the specific details on how the LMA can
formulate such flow policy is outside the scope of this document.
Melia & Gundavelli Expires September 14, 2016 [Page 13]
Internet-Draft Logical Interface Support March 2016
7. IANA Considerations
This specification does not require any IANA Actions.
Melia & Gundavelli Expires September 14, 2016 [Page 14]
Internet-Draft Logical Interface Support March 2016
8. Security Considerations
This specification explains the operational details of Logical
interface on an IP host. The Logical Interface implementation on the
host is not visible to the network and does not require any special
security considerations.
Different layer-2 interfaces and the access networks to which they
are connected have different security properties. For example, the
layer-2 network security of an end-user operated Wireless LAN network
is in the control of the home user and whereas an LTE operator has
the control on the layer-2 security of the LTE access network. An
external entity using lawful means, or through other means obtain the
security keys from the LTE operator and the same may not be possible
in the case of a home user operated wireless LAN network. Therefore,
grouping interfaces with such varying security properties into one
logical interface could have negative consequences in some cases.
Such differences though subtle, are entirely hidden by logical
interfaces and are unknown to the upper layers.
Melia & Gundavelli Expires September 14, 2016 [Page 15]
Internet-Draft Logical Interface Support March 2016
9. Authors
This document reflects contributions from the following authors
(listed in alphabetical order):
Carlos Jesus Bernardos Cano
cjbc@it.uc3m.es
Antonio De la Oliva
aoliva@it.uc3m.es
Yong-Geun Hong
yonggeun.hong@gmail.com
Kent Leung
kleung@cisco.com
Tran Minh Trung
trungtm2909@gmail.com
Hidetoshi Yokota
yokota@kddilabs.jp
Juan Carlos Zuniga
JuanCarlos.Zuniga@InterDigital.com
10. Acknowledgements
The authors would like to acknowledge all the discussions on this
topic in NETLMM and NETEXT working groups. The authors would also
like to thank Joo-Sang Youn, Pierrick Seite, Rajeev Koodli, Basavaraj
Patil, Peter McCann, Julien Laganier, Maximilian Riegel, Georgios
karagian, Stephen Farrell, Benoit Claise for their inputs to the
document.
11. References
Melia & Gundavelli Expires September 14, 2016 [Page 16]
Internet-Draft Logical Interface Support March 2016
11.1. Normative References
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, DOI 10.17487/RFC5213, August 2008,
<http://www.rfc-editor.org/info/rfc5213>.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010,
<http://www.rfc-editor.org/info/rfc5844>.
11.2. Informative References
[I-D.ietf-netext-pmipv6-flowmob]
Bernardos, C., "Proxy Mobile IPv6 Extensions to Support
Flow Mobility", draft-ietf-netext-pmipv6-flowmob-17 (work
in progress), March 2016.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
<http://www.rfc-editor.org/info/rfc2863>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6
over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007,
<http://www.rfc-editor.org/info/rfc5072>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275,
July 2011, <http://www.rfc-editor.org/info/rfc6275>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<http://www.rfc-editor.org/info/rfc7223>.
[TS23401] "3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; General
Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN)
access.", 2009.
[TS23402] "3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects;
Architecture Enhancements for non-3GPP Accesses.", 2009.
Melia & Gundavelli Expires September 14, 2016 [Page 17]
Internet-Draft Logical Interface Support March 2016
Authors' Addresses
Telemaco Melia (editor)
Kudelski Security
Geneva
Switzerland
Email: telemaco.melia@gmail.com
Sri Gundavelli (editor)
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sgundave@cisco.com
Melia & Gundavelli Expires September 14, 2016 [Page 18]
