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
- Re: [manet] MANET Terminology Update Dearlove, Christopher (UK)
- [manet] MANET Terminology Update Abdussalam Baryun
- Re: [manet] MANET Terminology Update Abdussalam Baryun
- Re: [manet] MANET Terminology Update Stan Ratliff
- Re: [manet] MANET Terminology Update Charles E. Perkins
- Re: [manet] MANET Terminology Update Abdussalam Baryun
- Re: [manet] MANET Terminology Update Teco Boot
- Re: [manet] MANET Terminology Update Abdussalam Baryun
- Re: [manet] MANET Terminology Update Teco Boot
- Re: [manet] MANET Terminology Update Stan Ratliff
- Re: [manet] MANET Terminology Update Abdussalam Baryun
- Re: [manet] MANET Terminology Update Teco Boot
- Re: [manet] MANET Terminology Update Ulrich Herberg
- Re: [manet] MANET Terminology Update Don Sturek
- Re: [manet] MANET Terminology Update Abdussalam Baryun
- Re: [manet] MANET Terminology Update Abdussalam Baryun
- Re: [manet] [Roll] MANET Terminology Update Jiazi YI
- Re: [manet] MANET Terminology Update Abdussalam Baryun
- Re: [manet] MANET Terminology Update Thomas Heide Clausen
- Re: [manet] MANET Terminology Update Abdussalam Baryun
- Re: [manet] MANET Terminology Update Abdussalam Baryun
- Re: [manet] MANET Terminology Update Stan Ratliff (sratliff)
- [manet] Fwd: MANET Terminology Update Stan Ratliff (sratliff)
- Re: [manet] MANET Terminology Update Joe Macker
- Re: [manet] MANET Terminology Update Don Sturek
- Re: [manet] MANET Terminology Update Ulrich Herberg
- Re: [manet] MANET Terminology Update Bo Berry