One document matched: draft-ng-nemo-ce-req-02.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="no"?>
<?rfc sortrefs="yes"?>
<!-- ?rfc strict="yes"? -->
<rfc ipr='full3978' docName='draft-ng-nemo-ce-req-02'>
<!---------------------------------------------------------------------------->
<!-- FRONT: Title, Authors, Abstract ----------------------------------------->
<!---------------------------------------------------------------------------->
<front>
<title abbrev='NEMO CE Requirements'>
Consumer Electronics Requirements for Network Mobility Route Optimization
</title>
<!-- Insert a link to your own authors XML -->
<?rfc include="author.chanwah.ng.xml"?>
<?rfc include="author.jun.hirano.xml"?>
<?rfc include="author.alexandru.petrescu.xml"?>
<?rfc include="author.eunkyoung.paik.xml"?>
<date month="February" year="2008" />
<area>Internet</area>
<workgroup>NEMO Working Group</workgroup>
<keyword>NEMO</keyword>
<keyword>Route Optimization</keyword>
<keyword>Consumer Electronics</keyword>
<abstract>
<t>
This document illustrates different deployments of Network Mobility (NEMO)
from the consumer electronics perspective. From these deployments, a set
of requirements is deduced for Route Optimization (RO) with NEMO.
</t>
</abstract>
</front>
<!---------------------------------------------------------------------------->
<!-- MIDDLE: Main Text ------------------------------------------------------->
<!---------------------------------------------------------------------------->
<middle>
<!---------------------------------------------------------------------------->
<!-- SECTION 1: INTRODUCTION ------------------------------------------------>
<!---------------------------------------------------------------------------->
<section anchor='sec:intro'
title="Introduction">
<t>
Network Mobility (NEMO) Basic Support <xref target="RFC3963"/> allows a whole
network to change its point of attachment while maintaining reachability
and session continuity. <xref target="RFC4888"/> and <xref target="RFC4889"/>
investigate the inefficiencies in NEMO Basic Support, and analyze the solution space
for Route Optimization (RO) with NEMO from a technical perspective.
</t>
<t>
This document explores the different deployment scenarios of NEMO from the
perspective of consumer electronics. This mainly entails a personal
device, called the Personal Mobile Router, as the primary node which
a user utilizes to allow the user's other devices to communicate with other
nodes in the global Internet. This is detailed in <xref target="sec:deploy"/>.
From these deployments, a set of requirements is inferred in <xref target="sec:req"/>.
</t>
<t>
It is expected for readers to be familiar with terminologies
related to mobility in <xref target="RFC3753"/>
and NEMO related terms defined in <xref target="RFC4885"/>.
Interested readers may also refer to <xref target="I-D.baldessari-c2ccc-nemo-req"/>
and <xref target="I-D.eddy-nemo-aero-reqs"/> for the requirements from the
automobile and aviation industries respectively.
</t>
</section> <!-- EndSect: Intro -->
<!---------------------------------------------------------------------------->
<!-- SECTION 2: DEPLOYMENTS ------------------------------------------------->
<!---------------------------------------------------------------------------->
<section anchor='sec:deploy'
title="Deployments of Personal Mobile Router">
<t>
The Personal Mobile Router is generally envisaged as a mobile communications device,
most probably a cellular handphone, with embedded router functionality so as to
allow other personal devices (such as MP3 Players, Digital Cameras) to access the
global Internet.
In such a deployment, it is expected for the Personal Mobile Router
to provide all the routing capabilities of the personal area network.
This means that one would generally not expect devices (i.e. LFNs)
such as digital camera or music players to have routing capabilities.
In other words, LFNs are envisaged as simple IPv6 hosts.
</t>
<t>
However, it is possible for there to be a Local Mobile Node (MNN)
in the personal area network. For instance, a laptop or a WLAN-enabled PDA
can break off from the personal area network and connect to the Internet
on its own. Thus, the device becomes a MIPv6 host, with its home address
configured from the Mobile Network Prefix of the personal area network.
</t>
<t>
This section illustrates three different deployment scenarios
with respect to the Personal Mobile Router. First is a simple personal
area network where NEMO services is provided by a service provider
(such as an telecommunications operator). Next is the deployment
where the Personal Mobile Router is docked within a car and serves as
an additional Mobile Router for the car network. The last scenario
is the case where the Personal Mobile Router obtains a network prefix
not directly from its Internet service providers. Instead, the
network prefix is allocated from the user's residence.
</t>
<vspace blankLines='1'/>
<section anchor='sec:deploy.PAN'
title="Simple Personal Area Network">
<!-- scenario -->
<t>
The simplest deployment is when the Personal Mobile Router is simply used to
provide Internet access to other devices in a user's personal area network.
This is the case where the user subscribes to a mobility service provider
that allocates a network prefix for the user's personal area network.
One example of this is the 3GPP Personal Network Management services
<xref target="3GPP.TS-22.259"/>.
</t>
<!-- Usage -->
<t>
For this scenario, typical communications will be audio/video streaming from a multimedia
content server to the music/video player in the user's personal area network.
This is a case of communications between a LFN with a CN in the global internet.
</t>
<figure anchor='fig:simple-PAN' title="Simple PAN deployment">
<artwork><![CDATA[
---------- ----
+-----------------| Internet |----| CN |
| ---------- ----
----------------
|Mobility Service|
| Provider |
----------------
|
/ | 3GPP
| --------
| | laptop | (MR)
| --------
PAN < |
(NEMO) | | wifi
| -------
| | PDA | (LFN)
\ -------
]]></artwork>
</figure>
<vspace blankLines='1'/>
<t>
An alternative situation will be communications between devices from two (or more)
different personal area networks. For example, two different users may engage in
a game with their personal entertainment devices (such as Nintendo or Play Station
portables), or share their audio files stored in their music players. This is a case of
communications between two LFNs from different NEMO.
</t>
<figure anchor='fig:simple-PAN-game' title="Communications between Two LFNs">
<artwork><![CDATA[
------------------
| Mobility Service |
| Provider (*) |
/ ------------------ \
/ \
| |
| 3GPP | 3GPP
-------- --------
| laptop | (MR) | laptop | (MR)
-------- --------
| |
| Wired | wifi
| |
-------- --------
|Nintendo| (LFN) |Nintendo| (LFN)
-------- --------
(*) - The two MRs may subscribe to the same or different Mobility
Service Provider(s)
]]></artwork>
</figure>
<!-- Adapted from Text Contributed by Eun Kyoung -->
<t>
An interesting scenario of a Personal Area Network that is beginning to emerge
is where the Personal Area Network is composed of a Personal Mobile Router
and wearable sensors. Typical deployment <xref target="Paper.HealthGear"/>
would be for a patient who wears
wearable sensors that monitor his/her physical conditions (eg., heartbeat,
body temperature, blood pressure, etc) periodically and transmit the
measurement to a hospital server through the Personal Mobile Router. This is a case
of communications between LFNs and a CN wherein the main traffic from the
LFN to the CN.
</t>
<figure anchor='fig:simple-PAN-sensor' title="Wearable Sensors Network for Medical Monitoring">
<artwork><![CDATA[
---------- ----------
+--------| Internet |----| Hospital | (CN)
| ---------- ----------
| GPRS
------------
| Cell Phone | (MR)
------------
|
+-----------+------------+
| Bluetooth |
---------- ---------------
(LFN) | Finger | | Earphone Body | (LFN)
| Oximeter | | Thermometer |
---------- ---------------
]]></artwork>
</figure>
<!-- Adapted from Text Contributed by Eun Kyoung -->
<vspace blankLines='1'/>
<!-- Adapted from Text Contributed by Alexandru Pretescu -->
<t>
A more complex use case for Personal Area Network can be described
as a dynamic change (scenario) between two different Personal Area
Network situations having the same entities. Each entity dynamically
changes its role (from, for example, MR to LFN), and, more importantly,
the routing task is moved from one entity to another.
</t>
<t>
Consider a Personal Area Network built from one PDA and one laptop.
In the first situation, the laptop is the Mobile Router. It uses its WiMax
interface to connect to the Internet and its WiFi interface to
offer access to the PDA. Following this, a second situation is
formed where the PDA connects its 3G interface to the Internet
(becoming the Mobile Router) and gives access to the laptop over
WiFi. This is illustrated in <xref target='fig:switch-MR'/> below.
</t>
<figure anchor='fig:switch-MR' title="Switching of Roles in PAN">
<artwork><![CDATA[
^ to Internet
|
| WiMax
-------- --------
| laptop | (MR) | laptop | (LFN)
-------- \ --------
| -----\ |
| wifi -----/ | wifi
| / |
------- -------
| PDA | (LFN) | PDA | (MR)
------- -------
| 3GPP
|
+-------> to Internet
]]></artwork>
</figure>
<t>
Both these situations can exist independently, as there are existing software
that is currently supporting these. For example, both Microsoft Windows XP
(laptop) and Windows Mobile (PDA) have the ability to connect one
interface to Internet and offer access over the other interface.
</t>
<t>
However, the automatic change between these two situations is not
possible without user intervention. The issues around this relate
to interface configuration, default route configuration and others.
If Mobile IP is used then there are additional issues with respect
to pre-established behavior (eg. use or do not use tunnels).
</t>
<t>
An example application where this support is needed is described next.
The scenario above describes the movement of the main routing task from the
laptop to the PDA. The routing task (run Mobile IP and NEMO, and
hide the LFN from mobility events) can be very consuming and can
compete with user interface events. For example, a user of a
laptop and PDA sets up the laptop as MR and PDA as LFN. The user continues
editing a document on the laptop. Then, another user arrives with
a laptop and needs access. At this point the first user is
actually interested in making the PDA to be MR (and not his/her
laptop) thus avoiding being disturbed by the more consuming routing
task of laptop (routing for two users is doubled).
</t>
<t>
Depending on the communicating applications, these kinds of
scenarios needing dynamic change of role of the entity performing
the routing task can be very numerous.
</t>
<!-- Adapted from Text Contributed by Alexandru Pretescu -->
</section> <!-- EndSect: Deployment -- PAN -->
<section anchor='sec:deploy.CAR'
title="Personal Mobile Router in a Car">
<!-- scenario -->
<t>
A second scenario involving the Personal Mobile Router is when the user docks
the Personal Mobile Router into a car network. This allows the communications devices
in the vehicle to use the Personal Mobile Router to access information from the
Internet. It also allows the personal devices in the personal area network to use the
Mobile Router in the vehicle network to communicate with correspondent nodes on
the Internet. In other words, the two mobile networks (personal area network and
vehicle network) merges to form a multihomed network.
</t>
<!-- Usage -->
<t>
There are two possible configurations that could arise. The first possible
configuration is where the car sensors and automotive devices are connected to
Car Mobile Router using a wired medium (such as the Controller Area Network, etc),
and the personal devices are connected to the Personal Mobile Router using a
wireless medium (such as the Bluetooth or Ultra Wide Band). The Personal Mobile
Router is connected to the Car Mobile Router via a docking mechanism installed
in the car. This is illustrated in <xref target='fig:car-net-1'/> below.
</t>
<figure anchor='fig:car-net-1' title="Separate Links in Merged NEMO">
<artwork><![CDATA[
WiMAX 3G
Car Sensors | | Personal Devices
& Automobile Devices | | (Eg. iPod, PSP, Lumix)
_ _ | | _ _
|_| |_| -------- -------- |_| |_|
| | | Car | |Personal| | |
--+--+----+--+---| Mobile |======| Mobile |-----+--+--+--
_ | _ | | Router | Dock | Router | _ |
|_|--+ |_|--+ -------- -------- |_|--+
<----- CAR NEMO -----> <------- PAN ------>
]]></artwork>
</figure>
<t>
In such a merged network, the vehicle network devices and the personal area network devices
will continue to use their own original network prefixes to communicate with external
nodes. Hence, one way to view this is to treat it as if the two Mobile Routers
attaches to each other, and uses each other as an additional access router.
This implies that the a communication between a MNN and a correspondent node may go
through two Mobile Routers (e.g. the communication from the car navigation device
to a traffic condition server passes through first the Mobile Router of the car, and then
the Personal Mobile Router). Hence, this can be viewed as a case of a nested NEMO.
</t>
<t>
A second possibility is that the car network and the personal area network
fused into a single network with two mobile routers. One way this can happen
is when the two networks use the same wireless technology such as Bluetooth or
Wireless Universal Serial Bus as the interconnection medium. This is shown in
<xref target='fig:car-net-2'/> below. This is a typical NEMO with multiple
mobile routers and prefixes <xref target='RFC4980'/>.
The car devices are free to configure an address from the
Mobile Network Prefix of the Personal Mobile Router to communicate with
other correspondent nodes in the Internet (such as a realtime traffic monitoring server).
Similarly, the personal devices are free to configure an address from the
Mobile Network Prefix of the Car Mobile Router to communicate with
other correspondent nodes in the Internet (such as a You-Tube video server).
</t>
<figure anchor='fig:car-net-2' title="A Single Link in Merged NEMO">
<artwork><![CDATA[
WiMAX 3G
| |
-------- --------
| Car | |Personal|
| Mobile | | Mobile |
| Router | | Router |
_ _ -------- -------- _ _
|_| |_| | | |_| |_|
| | | | | |
--+--+----+--+---+---------------+-------+--+--+--
_ | _ | _ |
|_|--+ |_|--+ |_|--+
Car Sensors Personal Devices
& Automobile Devices (Eg. iPod, PSP, Lumix)
<------- Merged Into a Single NEMO --------->
]]></artwork>
</figure>
<!-- Adapted from Text Contributed by Eun Kyoung -->
<t>
When the car network and the personal area network fused into a single network,
LFNs in this single network can communicate with each other. For example, a sensor which
was a LFN of the personal area network senses the body temperature of the driver
and send this information to the activator which was a LFN of the car network
to make the car environment comfortable for the driver. Since the car network
and the personal area network became a single network, this communication is a case
of intra-NEMO communication.
</t>
<!-- Adapted from Text Contributed by Eun Kyoung -->
</section> <!-- EndSect: Deployment -- CAR -->
<section anchor='sec:deploy.HOME'
title="Residence Home Network">
<!-- scenario -->
<t>
This scenario is a special deployment as it differs from the usual subscription model
that is more commonly used. Basically, in this scenario, the home network of the
Personal Mobile Router (as far as NEMO is concerned) is literally the "home" -- i.e.
the residence of the user. It is envisioned that the user deploys a residence-wide
network with a set-top box serving as the gateway. This set-top box is connected to
the Internet via broadband connection (cable or ADSL) and obtains an IPv6 prefix from
the ISP. Part of the IPv6 prefix obtained is then assigned as the prefix for the user's
personal are network (i.e. the Mobile Network Prefix for the personal area network).
The set-top box is thus configured as the home agent of the Personal Mobile Router.
</t>
<!-- Usage -->
<t>
Typically, the devices in the personal area network (i.e. LFNs) would communicate
mostly with other devices in the residence network (e.g. personal video player
accessing movie stored in a digital video recorder in the residence). In such
situation, route optimization is redundant. However,
there exist situations where multiple personal area networks
(each belonging to different family members) belong to the same residence network.
Devices from these different personal area networks may communicate with each other
often enough. In the latter situation, it is a case of two MNNs from different
NEMO communicating with each other.
</t>
</section> <!-- EndSect: Deployment -- HOME -->
</section> <!-- EndSect: Deployment -->
<!---------------------------------------------------------------------------->
<!-- SECTION 3: REQUIREMENTS ------------------------------------------------>
<!---------------------------------------------------------------------------->
<section anchor='sec:req'
title="Characteristics of Route Optimization for Consumer Electronics">
<t>
Not all communications involving personal area network require route optimization.
There are, however, two particular use cases where route optimization is highly
preferable. The first use case is when devices in a personal area network
are used for real time interactive applications which are sensitive to round trip
delays. Examples include voice-over-IP communications and multiplayer gaming
sessions. This usually entails communications between two devices from two different
personal area network, as illustrated in <xref target="sec:deploy.PAN"/> and
<xref target="sec:deploy.HOME"/>. In such cases, there might be two different
home agents involved (one for each NEMO), hence making the improvement in delay
reduction of route optimization more significant.
The second use case is when the home network is congested, or otherwise
bandwidth-limited. One example is the residence home network as described in
<xref target="sec:deploy.HOME"/>. Most broadband residence access
are asymmetrical (i.e. the uplink bandwidth is much smaller than the downlink
bandwidth), making it unsuitable for the home agent (e.g. set-top box) to forward
large amount of packets to Personal Mobile Routers.
</t>
<t>
Where route optimization is highly preferable, we can infer the following
requirements (denoted by "Req") in <xref target="sec:req.req"/> and
desirable features (denoted by "Des") in <xref target="sec:req.des"/>
from the deployment scenarios described in <xref target="sec:deploy"/>.
</t>
<section anchor='sec:req.req'
title="Required Characteristics">
<section anchor='sec:req.req1'
title="Req1: Unmodified LFNs">
<t>
A route optimization solution MUST operate even when LFNs are unmodified
<list style="hanging">
<t hangText="Rationale:">
<vspace blankLines='1'/>
Devices in the personal area network are envisaged as simple IPv6 node.
The Personal Mobile Router is expected to provide route optimization
services for any consumer electronic devices that connect to its
personal area network. Thus, it is expected for LFNs to remain unmodified
and unaware of mobile network's movement for route optimizations.
<vspace blankLines='1'/>
</t></list>
</t>
</section> <!-- Req1 -->
<section anchor='sec:req.req2'
title="Req2: Low Processing Load">
<t>
A route optimization solution MUST NOT increase the processing
load of the MR significantly
<list style="hanging">
<t hangText="Rationale:">
<vspace blankLines='1'/>
The Personal Mobile Router is a small mobile device (e.g. handphone)
that is limited in battery power. Hence, any route optimization
solution should not significantly increases the processing load of
the MR.
<vspace blankLines='1'/>
Processing load here is used to generally refer to the
computation load, signaling load, and memory storage requirements
for establishing and managing a route optimization
<vspace blankLines='1'/>
A quantitative requirement on what is the acceptable increase in processing
load is impossible to be specified; however, one possibility is to use
the current Mobile IPv6 Route Optimization as a benchmark reference.
A processing load increase for route optimization of a session is acceptable
if it is comparable to the amount of additional processing for Mobile IPv6
Route Optimization (i.e. the CoTI/CoT and HoTI/HoT signaling and adding of
home address destination option).
<vspace blankLines='1'/>
</t></list>
</t>
</section> <!-- Req2 -->
<section anchor='sec:req.req3'
title="Req3: Security">
<t>
A route optimization solution MUST NOT expose the mobile network
to additional security risk
<list style="hanging">
<t hangText="Rationale:">
<vspace blankLines='1'/>
Security is a prime consideration in the deployment of Personal
Mobile Router, since the personal area network may store private
information. In general, a personal area network would not allow
external devices to attach to the mobile network, hence the Personal
Mobile Router will the most important gateway in which security
of the personal area network is enforced. As such, any route
optimization solution should not expose the Personal Mobile Router
to additional risk as compared to NEMO Basic Support.
<vspace blankLines='1'/>
Particularly, it must not be possible for other nodes to claim
ownership of the Mobile Network Prefix (in entirety or in parts).
Additionally, denial-of service attacks on the Personal Mobile
Router (e.g. by forcing the Personal Mobile Router to send a huge
amount of signaling packets or to maintain a large number of
signaling states) must not be possible.
<vspace blankLines='1'/>
</t></list>
</t>
</section> <!-- Req3 -->
<section anchor='sec:req.req4'
title="Req4: Protocol Harmony">
<t>
A route optimization solution MUST NOT break or prevent the use of
existing protocols
<list style="hanging">
<t hangText="Rationale:">
<vspace blankLines='1'/>
As LFNs are assumed to be unmodified (see Req1), the communications
protocols used by them must not be modified as well. A route
optimization solution used by the Personal Mobile Router must not
cause any communications between the LFN and its correspondent node
to stop working. In other words, LFNs should be able to continue
to use any protocols that they are able to use without route optimization.
This includes IPSec and other IP layer signaling protocols.
<vspace blankLines='1'/>
</t></list>
</t>
</section> <!-- Req4 -->
</section> <!-- Req -->
<section anchor='sec:req.des'
title="Desired Characteristics">
<section anchor='sec:req.des1'
title="Des1: MR-to-MR Route Optimization">
<t>
As seen in <xref target="sec:deploy"/>, most of the communications
we envisaged are in the form of a MNN communicating with another MNN
in different personal area networks. As we do not expect MNNs to be
involved in route optimization signaling, a suitable route optimization
would likely be between the two MRs. This way, correspondent nodes would
not be impacted.
</t>
</section> <!-- Des1 -->
<section anchor='sec:req.des2'
title="Des2: Nested-NEMO Route Optimization">
<t>
In <xref target="sec:deploy.CAR"/>, a scenario is illustrated where
the Personal Mobile Router is attaching to the car mobile router for
Internet access (and vice versa). If the car mobile router performs
route optimization for its network, then the Personal Mobile Router
can run a separate route optimization session to achieve fully-optimized
route. Alternatively, it is also possible for the Personal Mobile Router
to support some mechanism that achieve nested-NEMO route optimization.
</t>
<t>
This desired feature can be generally extended to other forms of nesting
where the user brings a PAN into a larger mobile network, such as in a
plane, a train, or a ship. It is desired that a route optimization
solution should yield a fully optimized route regardless of whether
the Mobile Router of the larger mobile network performs route optimization
or not.
</t>
</section> <!-- Des2 -->
<section anchor='sec:req.des3'
title="Des3: Intra-NEMO Route Optimization">
<t>
In <xref target="sec:deploy.CAR"/>, a scenario is illustrated where
nodes in a the car network and nodes in the personal area network
communicates with each other. It is desirable that any route optimization
solution would work for intra-NEMO communications as well. It will be
even preferable if such intra-NEMO route optimizations can be achieved
without sending signalling messages out of the mobile network.
</t>
</section> <!-- Des3 -->
<section anchor='sec:req.des4'
title="Des4: Separability">
<t>
As route optimization would inevitably increase the processing load of
the Personal Mobile Router, it would be desired that the user be able to
select route optimization for some traffic and use the bi-directional
tunnel with home agent for other traffic. In other words, a route
optimization solution should preferably not be a "all-or-nothing"
mechanism. It should be possible to have both route optimized flows and
non-optimized sessions simultaneously.
</t>
</section> <!-- Des4 -->
<section anchor='sec:req.des5'
title="Des5: Multihoming">
<t>
As described in <xref target="sec:deploy.PAN"/>, it is likely for a
PAN to be equipped with multiple access technologies. Thus, it is
desirable that a route optimization solution be able to make use of
multiple access networks when available. It is also desirable to have
this feature regardless of whether all the available access to external
networks reside in one or multiple devices. For instance, in
<xref target="sec:deploy.CAR"/>, a scenario is described where there
are two Mobile Routers in the merged network.
</t>
</section> <!-- Des5 -->
</section> <!-- Des -->
</section> <!-- EndSect: Requirements -->
<!--------------------------------------------------------------------------->
<!-- SECTION: IANA CONSIDERATION ------------------------------------------>
<!--------------------------------------------------------------------------->
<section anchor='sec:IANA'
title="IANA Considerations">
<t>
This is an informational document and does not require any IANA action.
</t>
</section>
<!--------------------------------------------------------------------------->
<!-- SECTION: SECURITY CONSIDERATION ------------------------------------------>
<!--------------------------------------------------------------------------->
<section anchor='sec:security'
title="Security Considerations">
<t>
Security is a prime consideration in the deployment of Personal
Mobile Router. The requirements for security involving the Personal
Mobile Router are discussed in <xref target="sec:req"/>.
</t>
</section>
<!--------------------------------------------------------------------------->
<!-- SECTION: ACKNOWLEDGMENT ------------------------------------------>
<!--------------------------------------------------------------------------->
<!--section anchor='sec:Ack'
title="Acknowledgment">
<t>
The authors would like to express thank (in alphabetical
order) Paik Eun Kyoung (KT) and Alexandru Petrescu (Motorola) for their
gracious contributions to this memo.
</t>
</section>
<vspace blankLines='1'/-->
</middle>
<!---------------------------------------------------------------------------->
<!-- BACK: References and Appendix ------------------------------------------->
<!---------------------------------------------------------------------------->
<back>
<references title="Normative Reference">
<?rfc include="reference.RFC.3753.xml" ?>
<?rfc include="reference.RFC.4885.xml" ?>
</references>
<references title="Informative Reference">
<?rfc include="reference.RFC.3963.xml" ?>
<?rfc include="reference.RFC.4888.xml" ?>
<?rfc include="reference.RFC.4889.xml" ?>
<?rfc include="reference.RFC.4980.xml" ?>
<?rfc include="reference.I-D.eddy-nemo-aero-reqs.xml" ?>
<?rfc include="reference.I-D.baldessari-c2ccc-nemo-req.xml" ?>
<?rfc include="reference.3GPP.TS-22.259.xml" ?>
<?rfc include="reference.Paper.HealthGear.xml" ?>
</references>
<!---------------------------------------------------------------------------->
<!-- APPENDIX: CHANGE-LOG --------------------------------------------------->
<!---------------------------------------------------------------------------->
<section anchor="sec:changelog"
title="Change Log">
<t>
<list style="symbols">
<t>
draft-ng-nemo-ro-req-02:
<list style="symbols">
<t>
Added "Protocol Harmony" as requirement
</t>
<t>
Added "Separability" and "Multihoming" as desired feature
</t>
<t>
Elaborated more on some of the explanations of requirements
</t>
</list>
</t>
<t>
draft-ng-nemo-ro-req-01:
<list style="symbols">
<t>
Expanded <xref target='sec:deploy.CAR'/> to include different possible
configurations
</t>
<t>
New scenarios in <xref target='sec:deploy.PAN'/> and <xref target='sec:deploy.CAR'/>
</t>
<t>
Organized <xref target='sec:req'/> to have one-liner requirements, followed
by the explanation to give a more concise presentation
</t>
<t>
Added Jun, Eun Kyoung and Alexandru as co-authors
</t>
<t>
Various other editorial fixes
</t>
</list>
</t>
<t>
draft-ng-nemo-ro-req-00:
<list style="symbols">
<t>
Initial version.
</t>
</list>
</t>
</list>
</t>
</section> <!-- EndSect: Change-Log -->
</back>
</rfc>
<!-- End of Doc -->
| PAFTECH AB 2003-2026 | 2026-04-23 08:24:34 |