Internet DRAFT - draft-templin-manet-autoconf-link
draft-templin-manet-autoconf-link
Network Working Group F. Templin
Internet-Draft Boeing Phantom Works
Intended status: Informational August 24, 2006
Expires: February 25, 2007
Observations on "Link" in MANET/Autoconf and Other Contexts
draft-templin-manet-autoconf-link-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 25, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Mobile Ad-hoc Networks (MANETs) comprise MANET routers, and connect
to other networks via one or more MANET border routers. MANET
routers communicate over semi-broadcast links which present
interesting considerations for the classical IP model that are
subject matter for this document. In particular, the term "link"
requires careful examination in MANET/Autoconf and other contexts.
Templin Expires February 25, 2007 [Page 1]
Internet-Draft Observations on "Link" August 2006
1. Introduction
Mobile Ad-hoc Networks (MANETs) comprise MANET Routers (MRs) that
participate in a routing protocol over semi-broadcast links such that
intra-MANET packet forwarding may require multiple hops. MANETs
attach to other networks via zero or more MANET Border Routers
(MBRs), and MRs may be multiple forwarding hops away from their
nearest MBR. The Internet Protocol (IP) operates with minimal/no
enhancement over most link types, but semi-broadcast links can blur
the distinction of traditionally acknowledged link boundaries due to
interactions between network sublayers that are not widely discussed
in modern literature. This document examines the term "link" and its
meaning within different network sublayer viewpoints in MANET/
Autoconf and other contexts.
2. Terminology
The terminology in the references apply; the following terms are
defined within the scope of this document:
semi-broadcast
any link over which a MANET router's transmission coverage may be
restricted and/or time-varying due to range limitations, terrain
features, signal intermittence, etc. Links used in ad-hoc
wireless networks are the classic example, but the common link
types listed in ([RFC2461], Section 2.2) are also covered under
this definition.
Mobile Ad-hoc Network (MANET)
a connected network region (i.e., a "site") comprising MANET
routers that maintain a routing structure among themselves in a
relatively arbitrary fashion over semi-broadcast links. Further
information on the characteristics of MANETs can be found in
[RFC2501].
MANET Interface
a MANET router's attachment to a semi-broadcast link via a module
that implements network sublayers below IP. The MANET interface
preserves the architectural semantics of IP.
MANET Router (MR)
a node that participates in a routing protocol over one or more
MANET interface(s) and has zero or more interfaces attached to
downstream links.
Templin Expires February 25, 2007 [Page 2]
Internet-Draft Observations on "Link" August 2006
MANET Border Router (MBR)
an MR that is a site border router and connects the MANET to other
networks.
link-scoped service
a service that is accessed within the scope of the local link,
i.e., within a single IP hop. Examples are IPv6 Neighbor
Discovery, IPv4 Router Discovery, DHCP for IPv4, and client-side
aspects of DHCP for IPv6.
3. Observations on "link" in MANET/Autoconf and Other Contexts
3.1. Classical Definition for "Link"
The term "link" is (re)defined in numerous IETF documents, with
perhaps the most widely-cited examples appearing in
([RFC1256][RFC2461][RFC3753]) where the definitions for "link" are
mutually compatible. The balance of this document assumes the
RFC2461 version as representing a classical definition for "link":
link
a communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer immediately below
IP. Examples are Ethernets (simple or bridged), PPP links, X.25,
Frame Relay, or ATM networks as well as internet (or higher) layer
"tunnels", such as tunnels over IPv4 or IPv6 itself.
where it is also understood that links are bounded by routers that
decrement the IP Hop Limit/TTL.
In addition, ([TANENBAUM2], Section 1.2) and ([TANENBAUM4], Section
1.2.3) provide detailed discussion of the term "subnet" which clearly
shows that the author intended the term in a manner that matches the
IETF classical definition for "link". ([TANENBAUM4], Section 5.6.2)
gives a second definition for "subnet" (not present in [TANENBAUM2])
that more closely matches its use in the current IETF literature, but
the balance of this document cites [TANENBAUM2] and substitutes the
term "link" where the author uses the term "subnet".
3.2. Sublayers of Layer 3
Quoting from ([TANENBAUM2], pp. 321-324), the OSI networking model
included a conceptual 3-sublayer decomposition of Layer 3 as follows:
Templin Expires February 25, 2007 [Page 3]
Internet-Draft Observations on "Link" August 2006
internet sublayer (Layer 3c)
The principal task of the internet sublayer is end-to-end routing.
When a packet arrives at a relay, it works its way up to the
internet sublayer, which examines it and decides whether to
forward it, and if so, using which subnet (link) (a multilateral
relay may have several subnets (links) to choose from).
subnet (link) enhancement sublayer (Layer 3b)
The subnet (link) enhancement sublayer is designed to harmonize
subnets (links) that offer different services.
subnet (link) access sublayer (Layer 3a)
The purpose of the subnet (link) access layer is to handle the
network layer protocol for the specific subnet (link) being used.
It generates and receives data and control packets and performs
the ordinary network layer functions. The software is designed to
interface to the real subnet (link) available.
Applying this 3-sublayer decomposition to the modern architecture,
the IP protocol (versions 4 and 6) clearly occurs at Layer 3c. Layer
3b is NULL for many common link types such as multicast and point-to-
point, but special Layer 3a/b support may be required for other link
types such as ATM. (For MANETs, such Layer 3a/b support could be
said to occur at the MANET interface level from the viewpoint of IP).
The ARP protocol as well as the ARP cache and IPv6 neighbor cache
occur at Layer 3a, but it is important to note that the IPv4 Router
Discovery [RFC1256] and IPv6 Neighbor Discovery [RFC2461] protocols
occur at Layer 3c since they are integral components of the IP
protocol. The IP Forwarding Information Base (FIB) is managed by
entities across all three network sublayers.
3.3. Sublayer Views of "link"
MANETs operate over semi-broadcast links, but a MR's view of the link
depends on the particular sublayer in question.
o At Layer 3c, the MR's IP stack expects to see a fully-connected
link, i.e., one over which link-scoped transmissions can reach all
other MRs attached to the link in a single IP hop. Each link may
span a single access medium or multiple access media, but it is
the responsibility of lower (sub)layers to represent a fully-
connected link view to IP. This link view is covered under the
classical definition for link.
o At Layer 3b, a MR's link view consists of all nodes within
transmission range over one or more access media at a specific
point in time, and different MRs may have different Layer 3b link
Templin Expires February 25, 2007 [Page 4]
Internet-Draft Observations on "Link" August 2006
views that may vary over time. This link view is also covered
under the classical definition for link.
o At Layer 3a, a MR's link view consists of the set of pairwise
relationships established between itself and neighbors, i.e., the
Layer 3a link view is a set of point-to-point virtual links that
correspond to the L3-L2 address mappings in the ARP and/or IPv6
neighbor caches. (If a MANET interface attaches to multiple
access media, it can be said that it has multiple Layer 3a link
views that may/may not be merged into a single link view at Layer
3b.) Again, this link view is covered under the classical
definition for link.
As can be seen from the above, the Layer 3c link view is a fully-
connected overlay on top of (potentially) multiple Layer 3b link
views which are overlays on top of (potentially) multiple Layer 3a
link views.
3.4. MANET Layering Alternatives
MRs engage in a routing protocol to enable multihop forwarding, and
MANETs are bordered by zero or more MBRs that define the MANET (i.e.,
site) boundaries. Depending on the layering approach, the MANET may
appear as a single link or multiple links joined together by MRs,
e.g.:
o When MRs are configured to perform route calculations and packet
forwarding at Layer 2 (and a Layer 2 flooding mechanism is also
used), the routing protocol is essentially performing Layer 2
bridging, and each link is restricted to spanning similar access
media because media with dissimilar MTUs and Layer 2 address
formats cannot be bridged. In this approach, the Layer 3a link
view is initially NULL but may be populated with point-to-point
virtual links on-demand via either the ARP or IPv6 Neighbor
Discovery processes. Layer 3b may be NULL, and the Layer 3c view
of the MANET is the same as for one or more (bridged) campus LANs
joined together by routers.
o When MRs are configured for Layer 2 operation as above but also
distribute Layer 3 information, the routing protocol can be said
to occur at Layer 3a and the Layer 3a link view can be pre-
populated with point-to-point virtual links independently of the
ARP or IPv6 Neighbor Discovery mechanisms. Again, Layer 3b may be
NULL and the Layer 3c view of the MANET is the same as for the
Layer 2 case.
o When MRs are configured to perform route calculations and packet
forwarding at Layer 3 (and a Layer 3 flooding mechanism is also
Templin Expires February 25, 2007 [Page 5]
Internet-Draft Observations on "Link" August 2006
used), the routing protocol can be said to occur at Layer 3b. In
this approach, MRs can join dissimilar access media together to
represent the entire MANET as a single link to Layer 3c, since
Layer 3 mechanisms such as IP fragmentation and Path MTU Discovery
are available. Since multihop forwarding occurs at the IP layer,
however, the IP Hop Limit/TTL would be decremented for intra-MANET
packet forwarding which would break the semantics for IP link-
scoped transmissions. These IP Hop Limit/TTL issues can be
harmonized by Layer 3b link enhancement using IP-in-IP tunneling.
3.5. Layer 3b Link Enhancement
When MRs are configured to operate at Layer 3b, a non-enhanced view
of the link would be one that limits link-scope to transmission range
(i.e., the Layer 3c link view would be identical to the Layer 3b link
view).
To provide Layer 3c with a fully-connected view of the MANET, Layer
3b can perform IP-in-IP tunneling using the combined mechanisms of
6over4 [RFC2529] and ISATAP [RFC4214] with extensions to support all
variants of IP*/IP* tunneling instead of just IPv6/IPv4. A tunnel
MTU link adaptation mechanism [I-D.templin-linkadapt] can also be
used to provide an assured MTU in the presence of heterogeneous
access media.
This Layer 3b link enhancement function would be naturally
implemented as an embedded function within a MANET interface module
immediately below the IP stack such that link-scoped transmissions
are forwarded over a tunnel device and non-link-scoped transmissions
are forwarded either over the tunnel device or a native device if
possible. In particular, the MANET interface module would maintain
its own FIB (independent of IP's FIB) and use it to direct packets to
the correct egress device.
Using this Layer 3b enhancement, link-scoped services would work as-
normal across the MANET even though the MR and the on-link neighbor
that provides the service may be multiple Layer 3b hops apart,
because tunneling presents IP with the view of a single Layer 3c hop.
IPv6 Neighbor Discovery, IPv4 Router Discovery, DHCP for IPv4,
client-side aspects of DHCP for IPv6, and all other link-scoped
services would work as-normal across the MANET for this reason.
Without this Layer 3b enhancement, link-scope would be limited to a
MR's transmission range and as such all MRs would have to support
service-specific relays/servers for link-scoped services, since the
worst-case MANET topology is a linear string. An alternative would
be to specify new site-scoped services, but many standard services in
the Internet architecture are already specified as link-scoped and
Templin Expires February 25, 2007 [Page 6]
Internet-Draft Observations on "Link" August 2006
designed to work only within that scope.
4. Summary
This document shows that the Internet architecture conforms to
[TANENBAUM2]'s 3-sublayer decomposition for the OSI network layer
even though this is not widely discussed in modern literature. It
also shows that there is nothing wrong with the classical definition
for "link", but rather that the definition needs to be understood
within the context of individual network sublayers.
This document is written from a MANET/Autoconf perspective, and
examines MANET layering alternatives with respect to the OSI network
sublayers. It shows that standard link-scoped services are supported
as-normal on a MANET-wide basis when Layer 3b link enhancement (i.e.,
tunneling) is used. The document also raises the question of whether
site-scoped services could be used instead of link-scoped services in
order to avoid tunneling, and as such whether there is cause to re-
examine those aspects of the Internet architecture.
A further derivation that applies to all link types is that unicast
transmissions are ultimately carried over point-to-point links at
some level; the question becomes one of at which level the point-to-
point links are "bound":
o Hardwired point-to-point links are bound at Layer 1 and hence
privacy issues are restricted to physical security.
o Point-to-point links over certain wireless media (e.g., cellular)
are bound at Layer 2 and hence privacy issues are restricted to
the ability of a sophisticated eavesdropper to intercept wireless
transmissions and decrypt them - but the media is still a shared
media from the Layer 1 perspective.
o Multicast links are actually collections of virtual point-to-point
links that are bound at Layer 3a. Simple eavesdropping may be
available to some/all nodes on the link, hence privacy issues are
restricted to the ability of the eavesdropper to decrypt
intercepted transmissions - but the media is only a shared media
from the Layer 2 perspective and is really just a collection of
virtual point-to-point links above.
Finally, multicast transmissions over point-to-point links that are
bound at Layer 2 or below are carried as point-to-point over Layer 2
and hence are received by only one neighbor on the link. Multicast
transmissions over media with point-to-point links that are bound
above Layer 2 are carried as point-to-multipoint over Layer 2 and
Templin Expires February 25, 2007 [Page 7]
Internet-Draft Observations on "Link" August 2006
hence may be received by many neighbors on the link. The former
approach assures link quality and confidentiality by restricting the
link to a node and its serving router, while the latter approach
assures link quality and confidentiality by trusting neighbors on the
link to behave in a neighborly fashion.
The choice of which model to prefer is entirely up to the individual.
5. IANA Considerations
There are no IANA considerations associated with this document.
6. Security Considerations
Section 4 touches briefly on confidentiality, but no other aspects of
security are discussed.
7. Acknowledgements
The following individuals provided valuable input: Ian Chakeres,
Thomas Henderson, Steven Russert, Seung Yi.
David Young suggested the term "semi-broadcast" on the IETF MANET
mailing list. Phil Roberts encouraged the effort.
8. Informative References
[I-D.templin-linkadapt]
Templin, F., "Link Adaptation for IPv6-in-IPv4 Tunnels",
draft-templin-linkadapt-02 (work in progress), March 2006.
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and
Evaluation Considerations", RFC 2501, January 1999.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999.
Templin Expires February 25, 2007 [Page 8]
Internet-Draft Observations on "Link" August 2006
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler,
"Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP)", RFC 4214, October 2005.
[TANENBAUM2]
Tanenbaum, A., "Computer Networks - Second Edition,
Prentice Hall, Englewood Cliffs, NJ.", , 1989.
[TANENBAUM4]
Tanenbaum, A., "Computer Networks - Fourth Edition,
Prentice Hall, Uper Saddle River, NJ.", , 2003.
Author's Address
Fred L. Templin
Boeing Phantom Works
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
Email: fred.l.templin@boeing.com
Templin Expires February 25, 2007 [Page 9]
Internet-Draft Observations on "Link" August 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Templin Expires February 25, 2007 [Page 10]
