Re: [manet] MANET Terminology Update

Don Sturek <d.sturek@att.net> Mon, 23 July 2012 15:51 UTC

Return-Path: <d.sturek@att.net>
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 4F2F821F85F0 for <manet@ietfa.amsl.com>; Mon, 23 Jul 2012 08:51:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
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 pZsND1gDisnR for <manet@ietfa.amsl.com>; Mon, 23 Jul 2012 08:51:44 -0700 (PDT)
Received: from nm23.bullet.mail.ac4.yahoo.com (nm23.bullet.mail.ac4.yahoo.com [98.139.52.220]) by ietfa.amsl.com (Postfix) with SMTP id 2691721F85D3 for <manet@ietf.org>; Mon, 23 Jul 2012 08:51:44 -0700 (PDT)
Received: from [98.139.52.197] by nm23.bullet.mail.ac4.yahoo.com with NNFMP; 23 Jul 2012 15:51:41 -0000
Received: from [68.142.200.225] by tm10.bullet.mail.ac4.yahoo.com with NNFMP; 23 Jul 2012 15:51:40 -0000
Received: from [66.94.237.101] by t6.bullet.mud.yahoo.com with NNFMP; 23 Jul 2012 15:51:40 -0000
Received: from [127.0.0.1] by omp1006.access.mail.mud.yahoo.com with NNFMP; 23 Jul 2012 15:51:40 -0000
X-Yahoo-Newman-Id: 630312.19430.bm@omp1006.access.mail.mud.yahoo.com
Received: (qmail 5907 invoked from network); 23 Jul 2012 15:51:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1343058700; bh=ieYR6tIY8A2/t4iwnhhvECBeZT1P9cGQCAF+sIvHQxo=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=J+Ne+WQSDgwx/nTFQsGdCmn6VhXQinbHGiaS/Pe8vHTCnrtS3ruJ6xggnl6Ofbh/IXd/P7cTBBxaYNCL0W9dPmS9KCV1xVYuXks73Zk2IgjAMpW3Au7G3Kwu4xrwaZxlDrwFn3PKLnFRfBVQQlhD+8lDoEQDhGvW332ov7KaEvg=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: PAT9oJkVM1l3YnYkRKz4wZ4H1srU88JvuqncautSR0FEJAT n8Dl1.QZGWz0ns1VLdf9nH13R0mMFiflxqkbVZKNFZpB1SjV3Eh8YsvycJeu IMniWykpYzVGYNISOgIv2qjW1sLGPPISyyiGo4T3WYi_y0d5VaEACfSibH9B 7OnCFCLZl40B83tCZL0ryR7WH.M2Mt.KaI8ouQaap86xtN2utSP9_36o9L90 R.4LW064i.owC3axxhSyzbcbw6EHH2vylCs3qOv5sliQ8YpEEVOac8nGe_nX nIP6tr3ghkKcaQ7hcHQPsLxASbnEZI0DLWgdd5Hm1ofl2gqAiA1cw7AzCIia vaVzICSymD5NLe5ppQvucOT4LB8rWC9pJ2zjeH3t_SUol5e2nYK6WTuUJUkX .E5S7EbTwWPPzkVNi2P.vGUZRfA7yH_uh
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
Received: from [10.1.1.105] (d.sturek@66.27.60.174 with login) by smtp111.sbc.mail.ne1.yahoo.com with SMTP; 23 Jul 2012 08:51:39 -0700 PDT
User-Agent: Microsoft-MacOutlook/14.2.3.120616
Date: Mon, 23 Jul 2012 08:51:34 -0700
From: Don Sturek <d.sturek@att.net>
To: "Stan Ratliff (sratliff)" <sratliff@cisco.com>, Abdussalam Baryun <abdussalambaryun@gmail.com>
Message-ID: <CC32C0F2.185BE%d.sturek@att.net>
Thread-Topic: [manet] MANET Terminology Update
In-Reply-To: <8A25B620-D502-4C37-B292-B185331B1669@cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Cc: manet <manet@ietf.org>, Thomas Heide Clausen <thomas@thomasclausen.org>
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:51:46 -0000

+1

Agreed.  I don't see any value in MANET to the proposed I-D.

Don



On 7/23/12 7: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