draft-ietf-manet-packetbb-08.txt   draft-ietf-manet-packetbb-09.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique, France Internet-Draft LIX, Ecole Polytechnique, France
Intended status: Standards Track C. Dearlove Intended status: Standards Track C. Dearlove
Expires: January 10, 2008 BAE Systems Advanced Technology Expires: March 13, 2008 BAE Systems Advanced Technology
Centre Centre
J. Dean J. Dean
Naval Research Laboratory Naval Research Laboratory
C. Adjih C. Adjih
INRIA Rocquencourt INRIA Rocquencourt
July 9, 2007 September 10, 2007
Generalized MANET Packet/Message Format Generalized MANET Packet/Message Format
draft-ietf-manet-packetbb-08 draft-ietf-manet-packetbb-09
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2008. This Internet-Draft will expire on March 13, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document specifies a multi-message packet format that may be This document specifies a multi-message packet format that may be
used by mobile ad hoc network routing and other protocols. used by mobile ad hoc network routing and other protocols.
skipping to change at page 2, line 23 skipping to change at page 2, line 23
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 7 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 7
5. Signaling Framework . . . . . . . . . . . . . . . . . . . . . 8 5. Signaling Framework . . . . . . . . . . . . . . . . . . . . . 8
5.1. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 11 5.2.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 11
5.3. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 13 5.3. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 13
5.3.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.3.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3.2. Constraints . . . . . . . . . . . . . . . . . . . . . 16 5.3.2. Constraints . . . . . . . . . . . . . . . . . . . . . 16
5.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.3.3. Malformed Elements . . . . . . . . . . . . . . . . . . 16
5.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. TLV specification . . . . . . . . . . . . . . . . . . . . . . 18 6. TLV specification . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Address Block TLV Specification . . . . . . . . . . . . . 18 6.1. Address Block TLV Specification . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 23
A.1. Address Block Examples . . . . . . . . . . . . . . . . . . 23 A.1. Address Block Examples . . . . . . . . . . . . . . . . . . 23
A.2. TLV Examples . . . . . . . . . . . . . . . . . . . . . . . 24 A.2. TLV Examples . . . . . . . . . . . . . . . . . . . . . . . 24
skipping to change at page 5, line 22 skipping to change at page 5, line 22
Packet - the top level entity in this specification. Packets are Packet - the top level entity in this specification. Packets are
transmitted over a single logical hop and are not forwarded. A transmitted over a single logical hop and are not forwarded. A
packet contains zero or more messages, and may contain a packet packet contains zero or more messages, and may contain a packet
header. header.
Message - the fundamental entity carrying protocol information, in Message - the fundamental entity carrying protocol information, in
the form of addresses and TLVs. Messages are transmitted in the form of addresses and TLVs. Messages are transmitted in
packets, and may be forwarded based on their header information. packets, and may be forwarded based on their header information.
Address - an address of the same length as the source IP address in Address - a number of octets of the same length as the source IP
the IP datagram carrying the packet. address in the IP datagram carrying the packet. The meaning of an
address is defined by the protocol using this specification.
TLV - a Type-Length-Value structure. This is a generic way in which TLV - a Type-Length-Value structure. This is a generic way in which
an attribute can be represented and correctly parsed, without the an attribute can be represented and correctly parsed, without the
parser having to understand the attribute. parser having to understand the attribute.
element - a syntactic entity defined in the regular expression Element - a syntactic entity defined in the regular expression
specification, represented using the notation <foo>. specification, represented using the notation <foo>.
<foo> - if <foo> is an 8 or 16 bit field then <foo> is also used to <foo> - if <foo> is an 8 or 16 bit field then <foo> is also used to
represent the value of that field. represent the value of that field.
? - zero or one occurrences of the preceding element. ? - zero or one occurrences of the preceding element.
* - zero or more occurrences of the preceding element. * - zero or more occurrences of the preceding element.
bar - a variable, usually obtained through calculations based on the bar - a variable, usually obtained through calculations based on the
skipping to change at page 6, line 24 skipping to change at page 6, line 24
the same size, deduced from IP. In the case of mixed IPv6 and IPv4 the same size, deduced from IP. In the case of mixed IPv6 and IPv4
addresses, IPv4 addresses are represented as IPv4-mapped IPv6 addresses, IPv4 addresses are represented as IPv4-mapped IPv6
addresses as specified in [2]. addresses as specified in [2].
The messages defined by this specification are designed to carry The messages defined by this specification are designed to carry
routing protocol signals between MANET routers, and to support scope routing protocol signals between MANET routers, and to support scope
limited diffusion, as well as point to point signaling in a multi-hop limited diffusion, as well as point to point signaling in a multi-hop
network. network.
The packets defined by this specification are designed to carry a The packets defined by this specification are designed to carry a
number of messages between in a single transmission. The packets may number of messages in a single transmission. The packets may be
be unicast or multicast and may use any transport protocol (TCP, UDP, unicast or multicast and may use any transport protocol (TCP, UDP,
...) appropriate to the protocol using this specification and may ...) appropriate to the protocol using this specification and may
travel over a single logical hop which might consist of one or more travel over a single logical hop which might consist of one or more
IP hops. When the diffusion mechanism enabled by this specification IP hops.
is employed, UDP may be most appropriate.
This specification is particularly appropriate for extensible This specification is particularly appropriate for extensible
protocols. It offers external extensibility in the form of new protocols. It offers external extensibility in the form of new
message types. It offers internal extensibility in the form of TLVs, message types. It offers internal extensibility in the form of TLVs,
which may be added to existing message types. which may be added to existing message types.
A protocol using the multi-message packet format defined by this A protocol using the multi-message packet format defined by this
specification may constrain the syntax (for example requiring a full specification may constrain the syntax (for example requiring a full
message header) and features (for example specifying the suggested message header) and features (for example specifying the suggested
diffusion mechanism) that the protocol will employ. diffusion mechanism) that the protocol will employ.
skipping to change at page 10, line 44 skipping to change at page 10, line 44
dependent (the message originator maintains a sequence number dependent (the message originator maintains a sequence number
specific to <msg-type>). This bit MUST be cleared ('0') if the specific to <msg-type>). This bit MUST be cleared ('0') if the
noorig bit is set ('1'). noorig bit is set ('1').
bits 5-7: are RESERVED and MUST each be cleared ('0') to be in bits 5-7: are RESERVED and MUST each be cleared ('0') to be in
conformance with this version of the specification. conformance with this version of the specification.
If bit 0 (noorig) and bit 3 (noseqnum) are both cleared, then the If bit 0 (noorig) and bit 3 (noseqnum) are both cleared, then the
message header provides for duplicate suppression. message header provides for duplicate suppression.
If bit 1 (nohoplimit) and bit 2 (nohopcount) are both cleared, If bit 1 (nohoplimit) is cleared, then the message header provides
then the message header provides for scope-delimited forwarding. for scope-delimited forwarding.
<msg-size> is a 16 bit field, specifying the size of the <message>, <msg-size> is a 16 bit field, specifying the size of the <message>,
counted in octets. counted in octets.
<originator-address> is an identifier of length equal to address- <originator-address> is an identifier of length equal to address-
length, which serves to uniquely identify the node that originated length, which serves to uniquely identify the node that originated
the message. the message.
<hop-limit> is an 8 bit field, which contains the maximum number of <hop-limit> is an 8 bit field, which contains the maximum number of
logical hops a message should be further transmitted. logical hops a message should be further transmitted.
<hop-count> is an 8 bit field, which contains the number of logical <hop-count> is an 8 bit field, which contains the number of logical
hops a message has traveled. hops a message has traveled.
<msg-seq-number> is a 16 bit field, which contains a unique number, <msg-seq-number> is a 16 bit field, which contains a unique number,
generated by the originator node. The <originator-address>, <msg- generated by the originator node. The <originator-address>, <msg-
seq-number>, and, if the typedep bit in the <msg-semantics> field seq-number>, and, if the typedep bit in the <msg-semantics> field
is set, the <msg-type> of a message serves to uniquely identify is set, the <msg-type> of a message serves to uniquely identify
the message in the network. the message in the network (within the time period until <msg-seq-
number> wraps around to a matching value).
5.2.1. Address Blocks 5.2.1. Address Blocks
An address is specified as a sequence of address-length octets of the An address is specified as a sequence of address-length octets of the
form head:mid:tail. An address block is an ordered set of addresses form head:mid:tail. An address block is an ordered set of addresses
sharing the same head and tail, and having individual mids. Network sharing the same head and tail, and having individual mids. Network
addresses may be represented using the PREFIX_LENGTH TLV defined in addresses may be represented using the PREFIX_LENGTH TLV defined in
Section 6. Section 6.
<address block> is defined by: <address block> is defined by:
skipping to change at page 16, line 5 skipping to change at page 16, line 5
Table 4 Table 4
For an address block TLV, the TLV applies to the addresses from For an address block TLV, the TLV applies to the addresses from
position index-start to position index-stop (inclusive) in the position index-start to position index-stop (inclusive) in the
address block, where the first address has position zero. address block, where the first address has position zero.
number-values is a variable, defined by: number-values is a variable, defined by:
* number-values = index-stop - index-start + 1 * number-values = index-stop - index-start + 1
<length> is omitted or is a 8 or 16 bit field according to Table 2. <length> is omitted or is a 8 or 16 bit field according to Table 2.
If present it MUST NOT be zero. If the multivalue bit is set If the multivalue bit is set ('1') then <length> MUST be an
('1') then <length> MUST be an integral multiple of number-values, integral multiple of number-values, and the variable single-length
and the variable single-length is defined by: is defined by:
* single-length = <length> / number-values * single-length = <length> / number-values
If the multivalue bit is cleared ('0'), then the variable single- If the multivalue bit is cleared ('0'), then the variable single-
length is defined by: length is defined by:
* single-length = <length> * single-length = <length>
<value> if present (see Table 2) is a field of length <length> <value> if present (see Table 2) is a field of length <length>
octets. In an address block TLV, <value> is associated with the octets. In an address block TLV, <value> is associated with the
skipping to change at page 16, line 41 skipping to change at page 16, line 41
TLVs with the same tlv-fulltype are, or are not, allowed in the same TLVs with the same tlv-fulltype are, or are not, allowed in the same
packet or message TLV block, respectively. packet or message TLV block, respectively.
Two or more TLVs with the same tlv-fulltype in the same address block Two or more TLVs with the same tlv-fulltype in the same address block
TLV block MUST NOT be associated with the same copy of an address TLV block MUST NOT be associated with the same copy of an address
(i.e. they must not have overlapping index ranges). (i.e. they must not have overlapping index ranges).
TLVs with the same tlv-fulltype associated with the same address TLVs with the same tlv-fulltype associated with the same address
block MUST be sorted in ascending index-start order. block MUST be sorted in ascending index-start order.
5.3.3. Malformed Elements
An element is malformed if it cannot be parsed according to its
syntatical specification (including if there are insufficient octets
available when a length is specified) or if a constraint (including,
but not only, those specified in Section 5.3.2) specified as one
which MUST be satisfied, is not. A protocol using this specification
MUST specify the action, or choice of actions, to be taken when a
packet containing such elements is received. Typical examples will
include discarding any affected message(s), or discarding the
complete packet.
5.4. Padding 5.4. Padding
Packet headers and messages MAY be padded to ensure 32 bit alignment Packet headers and messages MAY be padded to ensure 32 bit alignment
of each message contained within the packet and of the overall packet of each message contained within the packet and of the overall packet
length. length. Padding MAY also be used to ensure that all packets/messages
have the same size.
All elements are an integer multiple of octets, hence padding can be All elements are an integer multiple of octets, hence padding can be
accomplished by inserting an integer number of <pad-octet> elements accomplished by inserting an integer number of <pad-octet> elements
after the element that is to be 32 bit aligned. after the element that is to be 32 bit aligned.
The number of <pad-octet> elements required to achieve this 32 bit The number of <pad-octet> elements required to achieve this 32 bit
alignment is the smallest number (0 to 3) that, when added to the alignment is the smallest number (0 to 3) that, when added to the
size of the preceding elements, produces an integer multiple of 4. size of the preceding elements, produces an integer multiple of 4.
<pad-octet> is an 8 bit field with all bits cleared ('0'). <pad-octet> is an 8 bit field with all bits cleared ('0').
skipping to change at page 22, line 16 skipping to change at page 22, line 16
9.1. Normative References 9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
[2] Hinden, R. and S. Deering, "IP Version 6 Addressing [2] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", October 1998. Considerations Section in RFCs", RFC 2434, BCP 26, October 1998.
9.2. Informative References 9.2. Informative References
[4] Clausen, T. and P. Jacquet, "The Optimized Link State Routing [4] Clausen, T. and P. Jacquet, "The Optimized Link State Routing
Protocol", RFC 3626, October 2003. Protocol", RFC 3626, October 2003.
Appendix A. Examples Appendix A. Examples
This appendix contains some examples of parts of this specification. This appendix contains some examples of parts of this specification.
skipping to change at page 34, line 21 skipping to change at page 34, line 21
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Rsv |N|1|1|1|0| Message Size | | Message Type | Rsv |N|1|1|1|1| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix B.3. Message Body Appendix B.3. Message Body
skipping to change at page 46, line 24 skipping to change at page 46, line 24
<Emmanuel.Baccelli@inria.fr> <Emmanuel.Baccelli@inria.fr>
o Thomas Heide Clausen, LIX, Ecole Polytechnique, France, o Thomas Heide Clausen, LIX, Ecole Polytechnique, France,
<T.Clausen@computer.org> <T.Clausen@computer.org>
o Justin W. Dean, NRL, USA<jdean@itd.nrl.navy.mil> o Justin W. Dean, NRL, USA<jdean@itd.nrl.navy.mil>
o Christopher Dearlove, BAE Systems, UK, o Christopher Dearlove, BAE Systems, UK,
<chris.dearlove@baesystems.com> <chris.dearlove@baesystems.com>
o Satoh Hiroki, Hitachi SDL, Japan, <h-satoh@sdl.hitachi.co.jp> o Satoh Hiroki, Hitachi SDL, Japan, <hiroki.satoh.yj@hitachi.com>
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr> o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
o Monden Kazuya, Hitachi SDL, Japan, <monden@sdl.hitachi.co.jp> o Monden Kazuya, Hitachi SDL, Japan, <kazuya.monden.vw@hitachi.com>
Appendix E. Acknowledgements Appendix E. Acknowledgements
The authors would like to acknowledge the team behind OLSRv1, as The authors would like to acknowledge the team behind OLSRv1, as
specified in RFC 3626, including Anis Laouiti, Pascale Minet, Laurent specified in RFC 3626, including Anis Laouiti, Pascale Minet, Laurent
Viennot (all at INRIA, France), and Amir Qayyum (Center for Advanced Viennot (all at INRIA, France), and Amir Qayyum (Center for Advanced
Research in Engineering, Pakistan) for their contributions. Research in Engineering, Pakistan) for their contributions.
The authors would like to gratefully acknowledge the following people The authors would like to gratefully acknowledge the following people
for intense technical discussions, early reviews and comments on the for intense technical discussions, early reviews and comments on the
specification and its components: Joe Macker (NRL), Alan Cullen (BAE specification and its components: Joe Macker (NRL), Alan Cullen (BAE
Systems), Ian Chakeres (Boeing), Charlie E. Perkins (Nokia), Andreas Systems), Ian Chakeres (Motorola), Charlie E. Perkins (Nokia),
Schjonhaug (LIX), Florent Brunneau (LIX), Yasunori Owada (Niigata Andreas Schjonhaug (LIX), Florent Brunneau (LIX), Yasunori Owada
University) and the entire IETF MANET working group. (Niigata University) and the entire IETF MANET working group.
Authors' Addresses Authors' Addresses
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique, France LIX, Ecole Polytechnique, France
Phone: +33 6 6058 9349 Phone: +33 6 6058 9349
Email: T.Clausen@computer.org Email: T.Clausen@computer.org
URI: http://www.thomasclausen.org/ URI: http://www.thomasclausen.org/
Christopher M. Dearlove Christopher Dearlove
BAE Systems Advanced Technology Centre BAE Systems Advanced Technology Centre
Phone: +44 1245 242194 Phone: +44 1245 242194
Email: chris.dearlove@baesystems.com Email: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/ URI: http://www.baesystems.com/
Justin W. Dean Justin W. Dean
Naval Research Laboratory Naval Research Laboratory
Phone: +1 202 767 3397 Phone: +1 202 767 3397
 End of changes. 20 change blocks. 
27 lines changed or deleted 42 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/