Re: [manet] MANET Terminology Update

Joe Macker <jpmacker@gmail.com> Mon, 23 July 2012 15:37 UTC

Return-Path: <jpmacker@gmail.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2256C11E807F for <manet@ietfa.amsl.com>; Mon, 23 Jul 2012 08:37:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level:
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wILKQ3A6Vwux for <manet@ietfa.amsl.com>; Mon, 23 Jul 2012 08:37:04 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E872811E8096 for <manet@ietf.org>; Mon, 23 Jul 2012 08:37:03 -0700 (PDT)
Received: by yhq56 with SMTP id 56so6127415yhq.31 for <manet@ietf.org>; Mon, 23 Jul 2012 08:37:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=cs9jwicnShkMCQ8s1LJOdg6AKN29DGiGleShjgohJ20=; b=dfZskag9Ib5rJ5IZglYfXnW58pdYLiCevedA/gyR3r5lfcrkyzjvljnUepRvGFzxIo x++2aeIJ9GbaEX8KDNH7SDXQT64QAHbk8NV7ztmiQ3kOw5s2N4/bLkV4NJ5s0aCJCoY/ OxJDobmEbv40UStmvnq6IUdLbM+Om+iauzvE0vXPnpW6abNZP86tKJ4fMpX2pkhWXeG8 oQk0rZ/uouuGESjKrtrfQFOUJauMGEhY9cTIy3izsh91kytQSWu0MB19AhS5qMn2Op57 M4ahbRh5AwKdsAv8lQXyQ6uHXCl5UiCnlRr4CdGSPzTx9saA5roRlgq3/fAuh+shtVEL +sXw==
Received: by 10.236.161.72 with SMTP id v48mr14895514yhk.84.1343057823449; Mon, 23 Jul 2012 08:37:03 -0700 (PDT)
Received: from ?IPv6:2002:458c:9704:1234:3cc8:3c42:cdb1:edb9? ([2002:458c:9704:1234:3cc8:3c42:cdb1:edb9]) by mx.google.com with ESMTPS id q3sm12680492ani.15.2012.07.23.08.37.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Jul 2012 08:37:03 -0700 (PDT)
References: <CADnDZ89NQS+tFVDsBjb_TZ2B-jL-o95Gx2HA5AbpRf2a8CstSg@mail.gmail.com> <B4130C17-45C2-485D-B2E4-3B9E16CA85DD@gmail.com> <CADnDZ88AQf_GLxjqdbB47EsACg+gnxHX9YJW5PZpOJzC32bR+A@mail.gmail.com> <2C1F8976-FE53-4C49-9BA3-930BFB63A8F5@thomasclausen.org> <CADnDZ888Sh_edm4XmPvvzrgN8WAK+NAWMCZEh7PuG-wJYLbMeQ@mail.gmail.com> <8A25B620-D502-4C37-B292-B185331B1669@cisco.com>
In-Reply-To: <8A25B620-D502-4C37-B292-B185331B1669@cisco.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Message-Id: <30FD7097-ED54-4D5C-A1A2-7D45F62AFDB0@gmail.com>
X-Mailer: iPhone Mail (9B206)
From: Joe Macker <jpmacker@gmail.com>
Date: Mon, 23 Jul 2012 11:40:06 -0400
To: "Stan Ratliff (sratliff)" <sratliff@cisco.com>
Cc: manet <manet@ietf.org>, Thomas Heide Clausen <thomas@thomasclausen.org>, Abdussalam Baryun <abdussalambaryun@gmail.com>
Subject: Re: [manet] MANET Terminology Update
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Jul 2012 15:37:06 -0000

Additional +1 

I believe there is no need for this

Sent from my iPhone

On Jul 23, 2012, at 10:59 AM, "Stan Ratliff (sratliff)" <sratliff@cisco.com> wrote:

> I'm going to "+1" one (and only one) sentence in this email thread: 
> 
>> 
>> On 7/6/12, Thomas Heide Clausen <thomas@thomasclausen.org> wrote:
>>> I do not see the need for this terminology document in MANET:
>> 
> 
> In my opinion as a working group participant, this is an unnecessary distraction for the working group, and will not result in a meaningful document. I will not support it. 
> 
> Regards,
> Stan
> 
> 
> 
> 
> On Jul 23, 2012, at 2:58 AM, Abdussalam Baryun wrote:
> 
>> Hi
>> 
>> Comment inline below:
>> 
>> On 7/6/12, Thomas Heide Clausen <thomas@thomasclausen.org> wrote:
>>> I do not see the need for this terminology document in MANET:
>>> 
>>>    o    The RFCs published by the WG all do a good job of defining their proper
>>>        terminology and conventions in the sections, aptly named to this
>>>        effect -- and something which both the WG and the IESG has been very
>>>        vigilant in ensuring.
>> 
>> Agree
>> 
>>> 
>>>    o    Extracting this terminology, to present without the context of the RFC in
>>> 
>>>        which they are introduced and used, is both futile and a source
>>>        of errors and confusion.
>> 
>> It is not extracting any thing it is locating information in easy
>> location to be reached efficiently by researchers, or other WG
>> participants. In another reason, for example the RFC5444 and RFC6130
>> is providing a MANET standard, while any RFC in this WG is specifying
>> its own terminology and message format, but the reason was to bring
>> RFCs to have similar formating functions. The terminology RFCs in many
>> WGs does the same. RFC2501 is doing a good job to bring understanding
>> of MANET which the terminology informational RFCs are doing in each
>> concept/group-charter.
>> 
>>> 
>>>    o    The domain evolves, new protocols appear and introduce new concepts,
>>>        terms. This is captured by carefully defining such in the RFC specifying
>>>        that protocol. Any terminology document (aside from all its other issues,
>>>        indicated in this list) would likely be obsolete and incomplete before
>>> the
>>>        ink with which it was written was dry.
>> 
>> So when new concepts appear any WG needs to prepare updates I-D to
>> their information/standards/experiments so that knowledge is
>> consistent and concepts are updated as will (including terminology
>> document can be updated). Please note that our documents in MANET are
>> a source of information to any participant in IETF, so we need to
>> focus to not only produce new concepts/work but we see into
>> update/obsolete previous work if possible/necessary. other wise why
>> did the IETF make an option possibility to *update* and *obsolete* if
>> they are not needed for WGs.
>> 
>>> 
>>>    o    All RFCs in MANET uses no more than a small subset of the total MANET
>>>        (and Internet) terminology. A collective terminology document would,
>>>        therefore, necessarily be adding entropy to any single RFC and to the
>>>        WG (and to implementers of the WG protocols).
>> 
>> Please note that the bigest reason of terminology is that when WG
>> participants discuss things they don't misunderstand. Please note
>> there are many times in MANET WG there are misunderstood in technical
>> terms (I have references on the list to many incidence if you ask), so
>> if experts have this problem we need to solve it by a RFC document,
>> also we need to give the protocol user a sense of the general/specific
>> terminology (as we have MANET general format, MANET general
>> understanding, MANET general direction).
>> 
>>> 
>>>    o    Certainly, a large number of terms in this document are entirely out of
>>> scope
>>>        (such as those pertaining to non-MANET developed concepts or protocols,
>>>        e.g., those developed in other parts of the IETF), are useless for the WG
>>>        (such as, but not exclusively, "communication channel" and "communication
>>> 
>>>        medium"), are by nature ambiguous (such as, but not exclusively, "Upper
>>> Layer"
>>>        and "Node"), carry a legacy that renders them difficult to use (such as,
>>> but
>>>        not exclusively, "Logical (virtual) Link", "Physical Link", and "Link").
>>> 
>> 
>> I disagree that thoes terms are out of scope of the I-D of the MANETs
>> context terminology, because those terms you mentioned were used in
>> one/some MANET RFCs, so they need to be explained to bring all terms
>> together to make overall knowledge to internet community. Your
>> argument is right only if we are not specifying network-protocols, so
>> because we are doing a type of network, then our documents for it
>> SHOULD be *connected* by some combined meaning/knowledge *words*, so
>> other (i.e. all internet community) can understand, without any
>> possibility of misunderstanding (there are many examples I can give if
>> you want).
>> 
>> I thank you for your comments, and I will prepare a new version for the I-D,
>> 
>> Best Regards
>> 
>> Abdussalam Baryun
>> =====================
>>>>> On Jul 3, 2012, at 1:24 PM, Abdussalam Baryun wrote:
>>>>> 
>>>>>> Dear All
>>>>>> 
>>>>>> I completed the first version of draft on terminology and submited the
>>>>>> draft yesterday (with getting some techniq problem), but needed to
>>>>>> post to know the community feedback and advise. There are other terms
>>>>>> that was not yet included which will need some advise from you.
>>>>>> Thanking you,
>>>>>> 
>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>> Abbreviations Used in The submitted Document
>>>>>> 
>>>>>> AH   Authentication Header
>>>>>> DAD  Duplicate Address Detection
>>>>>> DPD  Duplicate Packet Detection
>>>>>> DoS  Denial of Service
>>>>>> ESP  Encapsulating Security Payload
>>>>>> IP   IPv4 or IPv6
>>>>>> ICMP Internet Control Message Protocol
>>>>>> IIB  Interface Information Base
>>>>>> ETX  Estimated Expected number of Transmission
>>>>>> FIB  Forwarding Information Base
>>>>>> LQI  Link Quality Indicator
>>>>>> L2   Data Link Layer (i.e. 2nd layer in ISO model)
>>>>>> L3   Internet Layer (i.e. 3rd layer in ISO model)
>>>>>> LLN  Low power and Lossy Network
>>>>>> MAC  Mediam Access Control
>>>>>> MIB  Management Information Base
>>>>>> MTU  Maximum Transmission Unit
>>>>>> NBMA Non-Broadcast Multi-Access link
>>>>>> NHDP Neighborhood Discovery Protocol
>>>>>> ND   IP Neighbor Discovery
>>>>>> OSPF Open Shortest Path First
>>>>>> RIB  Routing Information Base
>>>>>> SMF  Simplified Multicast Forwarding
>>>>>> TCP  Transmission Control Protocol
>>>>>> UDP  User Datagram Protocol
>>>>>> 
>>>>>> 2.3 Definitions for MANET Terms
>>>>>> 
>>>>>> 2.3.1 Terms Definition of MANET Communication:
>>>>>> 
>>>>>> Communications’ Technology or Facility:
>>>>>> The means employed by two or more devices/subsystems to transfer
>>>>>> and/or receive information between them in one way or two way
>>>>>> communication.  MANET communications often uses the wireless
>>>>>> transmission medium(s) and MAY use some wired mediums (e.g. free
>>>>>> space, air, water, antenna, coaxial cables, etc.)
>>>>>> 
>>>>>> Communication Medium:
>>>>>> The transceiver system (e.g. such as L2 systems, IEEE802.11 systems,
>>>>>> satellite system, etc.) that the routing device uses to communicates
>>>>>> through the transmission medium(s), by providing connectionless and/or
>>>>>> connection services that MAY be established. The system medium
>>>>>> includes MAC layer and MAY include the physical Layer.
>>>>>> 
>>>>>> Communication Channel:
>>>>>> A subdivision of the physical communication medium (i.e. radio carrier
>>>>>> signal bandwidth, or the system bandwidth) allowing possibly shared
>>>>>> independent uses of the medium. Channels may be made available by
>>>>>> subdividing the medium into; distinct time slots, distinct spectral
>>>>>> bands, or coding sequence, etc.
>>>>>> 
>>>>>> MANET Protocol:
>>>>>> The communication system/subsystem that operates and maintains the
>>>>>> ad hoc communication technology or facility within MANET. MANET routing
>>>>>> Protocols often apply distributed algorithms/techniques to disseminate
>>>>>> or forward routing messages within a MANET routing domain.
>>>>>> 
>>>>>> Topology:
>>>>>> An abstract representation of a network (physical or logical), as a
>>>>>> graph (G) whose topology is defined by a set of routers/bridges (V)
>>>>>> that
>>>>>> communicate through set of links (E), where the G = (V, E).
>>>>>> 
>>>>>> Physical-level Topology:
>>>>>> A topology of the communication medium networks consists of routing
>>>>>> devices and physical links. This topology information is updated by
>>>>>> devices’ technology in the L2 information Base.
>>>>>> 
>>>>>> Network-level Topology:
>>>>>> A topology of the communication system networks consists of routers and
>>>>>> links. This topology information is updated by routers in its RIB.
>>>>>> 
>>>>>> Multihop MANET:
>>>>>> A MANET that its node(s) MAY need(s) more than one IP hop to reach the
>>>>>> destination.
>>>>>> 
>>>>>> Reactive Routing:
>>>>>> An on-demand based routing protocol that operates route discover and
>>>>>> maintainance the route(s), to reach the demanded destination(s).
>>>>>> 
>>>>>> Proactive Routing:
>>>>>> A topology RIB based routing protocol that operates routes and
>>>>>> maintains
>>>>>> the network topology, to reach its known destination(s). Each router
>>>>>> maintains routes to all reachable destinations at all times, whether or
>>>>>> not there is currently any demand to deliver packets to those
>>>>>> destinations.
>>>>>> 
>>>>>> Upper Layer:
>>>>>> a protocol layer above IP layer (e.g. as TCP, UDP, OSPF).
>>>>>> 
>>>>>> MANET Domain: TBD
>>>>>> 
>>>>>> MANET Signaling:
>>>>>> Sending and exchanging some MANET messages/information.
>>>>>> 
>>>>>> 2.3.2 Terms Definition of MANET Elements
>>>>>> 
>>>>>> Node:
>>>>>> A device/subsystem that MUST implement IP and SHOULD participate in
>>>>>> MANET signaling. It either runs a MANET routing protocol or participate
>>>>>> in MANET signaling.
>>>>>> 
>>>>>> Router:
>>>>>> A MANET node that MUST implement a MANET routing protocol and forwards
>>>>>> IP packets not explicitly addressed to itself.
>>>>>> 
>>>>>> Host:
>>>>>> A node that is not a router. All destinations in MANET that receive
>>>>>> delivered data are hosts.
>>>>>> 
>>>>>> Link:
>>>>>> A link between two node interfaces. This link may be Logical
>>>>>> (i.e. virtual) link or physical link. Logical links are between two
>>>>>> logical interfaces and physical links are between two physical
>>>>>> interfaces. Links are either unidirectional or bidirectional
>>>>>> (links may be on-link and off-link: see RFC4861).
>>>>>> 
>>>>>> 
>>>>>> Physical Link:
>>>>>> a communication facility or medium over which the nodes can
>>>>>> communicate at the link layer, i.e., the layer immediately below
>>>>>> IP. Physical interfaces are the nodes’ attachment to physical links.
>>>>>> Physical Link types are point-to-point, NBMA, multicast capable,
>>>>>> and shared-media, etc (see link types in ND [RFC4861]).
>>>>>> 
>>>>>> Logical (virtual) Link:
>>>>>> a communication facility (at L3, or upper-layer) over which nodes can
>>>>>> communicate. This logical link is between two MANET interfaces exists
>>>>>> if either can be heard by the other.
>>>>>> 
>>>>>> Link MTU:
>>>>>> the maximum transmission unit (i.e. maximum unit size in octets), that
>>>>>> can be conveyed in one transmission unit over the link.
>>>>>> 
>>>>>> 
>>>>>> Node Interface:
>>>>>> A node's point of attachment to a link. Each node MUST have at least
>>>>>> one
>>>>>> interface that SHOULD be assigned an IP address. If there is/are more
>>>>>> than one interface(s) per node then the additional interface(s) MAY be
>>>>>> assigned an IP address. If an interface is not assigned to an IP
>>>>>> address
>>>>>> it MUST be identified by the MANET routing protocol. An interface MAY
>>>>>> be
>>>>>> assigned one or more addresses.
>>>>>> 
>>>>>> MANET Interface:
>>>>>> A node interface that participate in; exchange MANET information used
>>>>>> in
>>>>>> MANET routing or exchange information in MANET neighbor node discovery
>>>>>> (e.g as the term used in RFC6130). A MANET interface MUST be assigned
>>>>>> to
>>>>>> least one  address to communicate. A router interface MUST be
>>>>>> assigned a routable address which is the main address for the
>>>>>> interface.
>>>>>> 
>>>>>> 
>>>>>> 2.3.3 Terms Definition of MANET Identifications:
>>>>>> 
>>>>>> An interface MAY be assigned one or more addresses. If the interface is
>>>>>> a logical interface it MAY be assigned to only logical addresses, but
>>>>>> if
>>>>>> it is a physical interface MAY be assigned with physical address
>>>>>> (e.g. MAC address) and/or logical address(es) (e.g. IP addresses,
>>>>>> MANET addresses).
>>>>>> 
>>>>>> 
>>>>>> MANET Address
>>>>>> A MANET-subnet, node, or interface address. Node and interface
>>>>>> addresses
>>>>>> are either IP addresses or RFC5444 addresses. All subnet addresses are
>>>>>> unicast IP addresses.
>>>>>> 
>>>>>> Address Block and TLV: as specified in RFC5444
>>>>>> 
>>>>>> Routable address:
>>>>>> A subnet address which can be a destination address. A router MUST be
>>>>>> able to distinguish a routable address from a non-routable address.
>>>>>> Broadcast, and multicast addresses, limited in scope to less than the
>>>>>> entire MANET, MUST NOT be considered as routable addresses. Anycast
>>>>>> addresses MAY be considered as routable addresses.
>>>>>> 
>>>>>> Main address
>>>>>> A routable address (MANET address) that is assigned to one router's
>>>>>> MANET interface.
>>>>>> 
>>>>>> Originator address:
>>>>>> A node address of the node that originated a MANET message (this
>>>>>> message
>>>>>> MUST include the originator address). It MAY be a routable or an
>>>>>> unroutable address.
>>>>>> 
>>>>>> subnet prefix
>>>>>> A bit string that consists of some number of initial bits of an IP
>>>>>> address.
>>>>>> 
>>>>>> Interface identifier
>>>>>> the remaining low-order bits in the node's IP address after the subnet
>>>>>> prefix. A number used to identify a node's interface on a link.
>>>>>> 
>>>>>> 2.3.4 Terms Definition of MANET exchange information formats:
>>>>>> 
>>>>>> Packet:
>>>>>> A MANET packet of a header plus payload. These packets are either
>>>>>> IP packets or RFC5444 packets. RFC5444 packet MUST be encapsulated
>>>>>> in IP packet. Packets are generated by nodes to be sent to
>>>>>> destination(s) through MANET or through the Internet. RFC5444 packets
>>>>>> information MAY not be used only by MANET routers.
>>>>>> 
>>>>>> Message:
>>>>>> A MANET data message or routing control message. Routing control
>>>>>> messages are either MANET routing protocol messages or/and RFC5444
>>>>>> messages.
>>>>>> 
>>>>>> Type Length Value coding (TLV):
>>>>>> A generic way to represent MANET information (as in [RFC5444] and
>>>>>> [RFC5497]).
>>>>>> 
>>>>>> Frame:
>>>>>> A L2 protocol TLV with a header and payload. In some technologies the
>>>>>> L2
>>>>>> operates a MANET routing protocol as a local area networking system.
>>>>>> Frames MAY encapsulate MANET packets to be tunneled through a
>>>>>> telecommunication network.
>>>>>> 
>>>>>> Route Request Message (RREQ)
>>>>>> A message is used to discover a valid route to a particular
>>>>>> destination address, called the RREQ Target Node. When a router
>>>>>> processes a RREQ it learns routing information on how to Originator
>>>>>> Node.
>>>>>> 
>>>>>> Route Reply Message (RREP)
>>>>>> A message is used to disseminate routing information about
>>>>>> the RREP Target Node to the RREQ Originator Node and the intermediate
>>>>>> routers.
>>>>>> 
>>>>>> Route Error Message (RERR)
>>>>>> A message is used to disseminate the information that a route is
>>>>>> not available for one or more particular addresses. A RERR message is
>>>>>> used to indicate that a router does not have a forwarding route
>>>>>> to one or more particular addresses.
>>>>>> 
>>>>>> 2.3.5 Terms Definition Related to MANET Protocol Operation:
>>>>>> 
>>>>>> Hop-by-hop Routing: (TBD)
>>>>>> A dynamic routing that routes to destination by routing table.
>>>>>> 
>>>>>> Source Routing: (TBD)
>>>>>> A dynamic routing that its route path is provided in the IP packet.
>>>>>> 
>>>>>> Route Discovery: TBD
>>>>>> 
>>>>>> Route Maintenance: TBD
>>>>>> 
>>>>>> Neighbor discovery: (TBD)
>>>>>> A node discovers neighbors only if the node receives from it's
>>>>>> neighbors.
>>>>>> 
>>>>>> 
>>>>>> Multipoint relay (MPR): (TBD)
>>>>>> A router X1 is an MPR for a router Y1, if router Y1 has indicated
>>>>>> its selection of router X1 as an MPR in a recent HELLO message.
>>>>>> Router X1 may be a flooding MPR for Y1 if it is indicated to
>>>>>> participate in the flooding process of messages received from
>>>>>> router Y1, or it may be a routing MPR for Y1, if it is indicated to
>>>>>> declare link-state information for the link from X1 to Y1. It may
>>>>>> also be both at the same time.
>>>>>> 
>>>>>> MPR selector:
>>>>>> A router, Y, is a flooding/routing MPR selector of router X if
>>>>>> router Y has selected router X as a flooding/routing MPR.
>>>>>> 
>>>>>> Router Parameters:
>>>>>> boolean or numerical values, specified for each router, and not
>>>>>> specific to an interface. A router MAY change router parameter
>>>>>> values at any time, subject to some MANET constraints.
>>>>>> 
>>>>>> MANET Routing Metric:
>>>>>> A MANET routing cost that is governed by specific rules and properties
>>>>>> defined by the MANET routing protocol which captures specific link or
>>>>>> node characteristics. Examples of basic metrics are hop-count, ETX,
>>>>>> LQI,
>>>>>> etc.
>>>>>> 
>>>>>> Distance Vector Metric
>>>>>> A metric class related to rules of the MANET interface and MANET path
>>>>>> distance. The metric can be calculated by the distance vector routing
>>>>>> algorithm class used by the MANET routing protocol. A metric of the
>>>>>> distance a message or piece of information has traversed. The minimum
>>>>>> value of distance is the number of IP hops traversed.
>>>>>> 
>>>>>> Link State Metric
>>>>>> A metric type related to the MANET network-topology status and logical
>>>>>> links' states. This metric is calculated by the link state routing
>>>>>> algorithm class used by the MANET routing protocol. A metric type maybe
>>>>>> EXT, LQL, etc.
>>>>>> 
>>>>>> Link Metric: TBD
>>>>>> 
>>>>>> Neighbor Metric: TBD
>>>>>> 
>>>>>> Path accumulated:
>>>>>> The RREQ message accumulates intermediate routers that are in path to
>>>>>> destination(s).
>>>>>> 
>>>>>> Protocol Sequence Number:
>>>>>> A Sequence Number related to a MANET protocol that maintained by each
>>>>>> protocol subsystem process. This sequence number is used by other
>>>>>> subsystems to identify the temporal order of protocol information
>>>>>> generated.
>>>>>> 
>>>>>> Router Sequence Number:
>>>>>> A router sequence number is maintained by each router process. The
>>>>>> sequence number is used by other routers to identify the temporal
>>>>>> order of routing information generated and ensure loop-free routes.
>>>>>> 
>>>>>> MANET Information Base:
>>>>>> A collection of information (in Table or Cache structure) maintained
>>>>>> by MANET protocols and which is to be made available to MANET routing
>>>>>> protocols. An Information Base may be associated with a MANET router
>>>>>> or with MANET interface (e.g. route request table, IIB, RIB, FIB, MIB).
>>>>>> 
>>>>>> RIB Entry:
>>>>>> The RIB entry is a conceptual data structure. Implementations may use
>>>>>> any internal representation that conforms to the semantics of a route
>>>>>> as specified in the router specification.
>>>>>> 
>>>>>> 3. IP Considerations and Terminology
>>>>>> 
>>>>>> All MANET nodes MUST implement IP and all MANET routers MUST
>>>>>> run/implement  at least one MANET routing protocol. The
>>>>>> terminologies described in this document can be used for
>>>>>> IPv4-MANET and IPv6-MANET. The IPv4 addresses MAY be used in IPv6
>>>>>> packets but IPv6 addresses MUST not be in IPv4 packets.
>>>>>> 
>>>>>> IP address:
>>>>>> IPv4 addresses or IPv6 addresses.
>>>>>> 
>>>>>> IP Packet:
>>>>>> The packet header plus payload as specified in [RFC791] and [RFC2460]
>>>>>> for IPv4 and IPv6 respectively. It can encapsulate RFC5444 packets as
>>>>>> specified by RFC5498.
>>>>>> 
>>>>>> Mobile IP considerations:
>>>>>> Mobile IP terms are provided in [RFC6275], and this technology
>>>>>> assists nodes while connected through the Internet domain(s). MANET
>>>>>> is an infrastructure-less network that is able to communicate with
>>>>>> the Internet (i.e. an IP infrastructure network).
>>>>>> 
>>>>>> 4. Security Consideration and Terminology
>>>>>> 
>>>>>> It is RECOMMENDED that MANET routing protocols consider security
>>>>>> issues because the MANET's transmission medium is wireless which make
>>>>>> it vulnerable to attacks [ANJUM][RFC4593]. In some situations the
>>>>>> routing information while traversing the MANET MAY be used by an
>>>>>> intruder node, to obtain MANET data traffic or/and attack the MANET
>>>>>> [HERBERG]. Forwarding protocols that use DPD techniques MAY be
>>>>>> vulnerable to DoS attacks such as [RFC6621]. MANETs MAY be secured
>>>>>> by using IPsec, AH, DAD, and ESP techniques, and other. However,
>>>>>> it is RECOMMENDED that MANET detects attackers and possible threats.
>>>>>> 
>>>>>> The following are some terminology related to MANET threats and
>>>>>> security.
>>>>>> 
>>>>>> Attacker: A node, present in the network and which intentionally seeks
>>>>>> to compromise information based in MANET router(s). The Attacker MAY be
>>>>>> a compromised MANET router if obtained MANET identity or routing
>>>>>> information.
>>>>>> 
>>>>>> Compromised MANET Router: An attacker router, present in MANET and
>>>>>> which generates syntactically correct routing control messages. Control
>>>>>> messages emitted by compromised router(s) may contain additional
>>>>>> information, or omit information, as compared to a control message
>>>>>> generated by a non-compromised router located in the same MANET
>>>>>> topological position.
>>>>>> 
>>>>>> Legitimate MANET Router: A MANET router, which is not a Compromised
>>>>>> MANET Router.
>>>>>> 
>>>>>> Jamming Attack:
>>>>>> The attacker transmits massive amounts of interfering radio traffic,
>>>>>> which will prevent legitimate traffic (e.g., routing and data traffic)
>>>>>> on all or part of the MANET. Indirect jamming attacks MAY occur by
>>>>>> influencing Legitimate MANET Router to transmit unnecessary
>>>>>> information.
>>>>>> 
>>>>>> Eavesdropping:
>>>>>> Obtaining a copy by the attacker of the transmitted MANET routing
>>>>>> information or the transmitted data information from its neighbor's
>>>>>> transmitted radio packet. Attacker’s processes MANY be used by attacker
>>>>>> to mislead routing. Eavesdropping does not pose a direct threat to the
>>>>>> MANET or to its routing.
>>>>>> 
>>>>>> Identity Spoofing:
>>>>>> Attacker sends routing messages, pretending to have the MANET identity
>>>>>> of another node.
>>>>>> 
>>>>>> Link Spoofing:
>>>>>> Compromised MANET router sends routing messages to neighbor node(s)
>>>>>> providing incorrect set of link information.
>>>>>> 
>>>>>> Replay Attack:
>>>>>> A Compromised router in one MANET region records control traffic
>>>>>> information and replays the recorded information in a different MANET
>>>>>> region (this type of attack is also called the Wormhole attack).
>>>>>> 
>>>>>> Broadcast Storm:
>>>>>> Compromised MANET router may attack the MANET by attempting to change
>>>>>> the MANET flooding algorithm(s) to increase routing overheads or/and to
>>>>>> increase the route discovery delay. Broadcast storm degrades the data
>>>>>> traffic delivery and MANET performance.
>>>>>> 
>>>>>> Falsification in MANET:
>>>>>> The compromised MANET router sends false routing information into
>>>>>> MANET.
>>>>>> False routing information received in MANET, MAY create unrealistic
>>>>>> information bases.
>>>>>> 
>>>>>> ICMP Attacks:
>>>>>> The generation of ICMPv6 error messages may be used by compromised
>>>>>> MANET
>>>>>> router to attempt DoS attacks by sending an error-causing source
>>>>>> routing
>>>>>> header in back-to-back datagrams. As the ICMP messages are passed to
>>>>>> the
>>>>>> upper-layer processes, it is possible to perform attacks on the upper
>>>>>> layer protocols (e.g., UDP, TCP). Protocols at the upper layers are
>>>>>> RECOMMENDED to perform some form of validation to ICMP messages (using
>>>>>> the information contained in the payload of the ICMP message) before
>>>>>> acting upon them.
>>>>>> 
>>>>>> Source Routing Attacks: TBD
>>>>>> 
>>>>>> Acknowledgments:
>>>>>> 
>>>>>> This work has used/modified terms of the following documents: RFC2462,
>>>>>> RFC2501, RFC3561, RFC3626, RFC3753, RFC4728, RFC4861, RFC5444,
>>>>>> RFC6130,  RFC6621, [AODVv2], [OLSRv2], and [HERBERG],
>>>>>> Gratefully acknowledge to the IETF community and all contributions.
>>>>>> 
>>>>>> Reference:
>>>>>> [HERBERG] Herberg, U., Yi, J., Clausen, T.,"Security Threats for
>>>>>>          NHDP", Work in progress, March, 2012.
>>>>>> [ANJUM]   Anjum, F. and Mouchtaris, P. "Security for Wireless Ad Hoc
>>>>>>          Networks", John Wiley & Sons, March 2007.
>>>>>>          ISBN: 978-0-471-75688-0.
>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>> 
>>>>>> I hope to get some advise from the Internet community to make the
>>>>>> definitions more suitable/accurate, because I MAY misunderstood.
>>>>>> Thanking you,
>>>>>> 
>>>>>> Best Regards
>>>>>> 
>>>>>> Abdussalam Baryun
>>>>>> University of Glamorgan, UK
>>>>>> =====================
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet