Date: Fri, 29 Mar 2024 11:01:28 +0000 (UTC) Message-ID: <1301155414.1083.1711710088112@ip-10-30-146-46.us-west-2.compute.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1082_564693066.1711710088110" ------=_Part_1082_564693066.1711710088110 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The Neighbour Resolution Service provides an abstraction that ma= kes it easy for applications to specify how neighbour discovery packets (e.= g. ARP, NDP) should be handled for the slice of traffic that the applicatio= n is managing.
Previously applications had the option of implementing their own neighbo= ur message handling themselves on top of the PacketService, or to try and f= it their logic into an existing neighbour-handling application such as Prox= yARP. Solution one means that many apps contain very similar code to parse = and construct neighbour messages etc, even though they only have small diff= erences in the handling logic. Solution two becomes very complicated becaus= e multiple use cases have to be managed within a single application, and th= e logic becomes very complex.
The NeighbourResolutionService aims to solve these problems by allowing = an application to specify a NeighbourMessageHandler for a particular connec= t point or interface. The NeighbourMessageHandler is a small piece of logic= that decides how to handle the message, and conveys the result of that dec= ision to the NeighbourResolution framework. This separates decision l= ogic from mechanisms used to parse and generate packets, and it allows appl= ications to contribute their own handling logic that may read an applicatio= n-specific config or state, without having to insert this logic into an exi= sting application like ProxyARP.
The handler is specific to a switch port or interface, which means an ap= plication can register multiple different types of handlers for different p= orts or interfaces if it needs different neighbour message handling for the= m. For example, the SDN-IP application has different neighbour message hand= ling logic for ports where external peers are connected versus ports where = the internal BGP speaker is connected. This also allows multiple applicatio= ns to specify neighbour message handling at the same time, so long as they = don=E2=80=99t conflict in the connect points or interfaces that they add th= eir handers for. There should be a somewhat natural division of connect poi= nts or interfaces for different applications, because different application= s are interested in handling different slices of the traffic.
A handler must be registered with the NeighbourResolutionService for a p= articular connect point or interface. This means that the message handler w= ill receive packets that come in to the system from that connect point or i= nterface. Handlers are advised to be stateless, and therefore it is possibl= e to register the same handler instance at multiple connect points or inter= faces.
A handler registered for a connect point will receive all packets that c= ome to the control plane (e.g. via OpenFlow packet-ins) from that connect p= oint. A handler registered for an interface will receive all packets coming= to the control plane from that interface. This means they must come from t= he connect point that the interface references, and the packet headers must= match the parameters of the interface. For example, if the interface has a= VLAN configured, then only packets coming through the connect point with t= hat particular VLAN tag will be delivered to the neighbour message handler.= Likewise, if the interface has an IP address configured then only neighbou= r messages that target that configured IP address will be delivered to a ha= ndler registered for that interface.
NeighbourMessageHandlers operate on a higher layer abstraction than the = packet-ins and packet-outs that previous neighbour message logic was forced= to operate on. The handler receives a NeighbourMessageContext as its argum= ent. This context provides access to fields of the incoming packets that th= e handler may be interested in in a protocol-agnostic way, so the handler d= oesn=E2=80=99t have to reconcile the differences between ARP and NDP. The o= riginal incoming packet is also available if the handler is interested in a= field that is not available through the context API. The handler can easil= y see whether the message was a request or a reply, as it is common to requ= ire different logic for these different types of messages.
Apart from information about the incoming packet, the context API also p= rovides mechanisms for the handler to specify the decision it has made. The= re are currently four different decisions a handler can make: reply, forwar= d, flood, and drop. When the handler calls these APIs, the framework takes = care of performing the appropriate action. If none of these actions are app= ropriate for a handler, it is free to implement its own result (but it may = require more code to formulate an output packet, etc.). New actions may be = added to the framework if they are general enough to apply in a range of si= tuations.
To summarise, an application that is interested in using the NeighbourRe= solutionService to simplify its neighbour message processing must do two th= ings:
Please refer to the following APIs for Javadoc:
Neighbo= urResolutionService NeighbourMessageContext
A good application to look at for developers looking to see an example o= f the neighbour resolution service in use is the ProxyARP application (Prox= yARP does handle NDP messages as well). The ProxyARP application responds t= o ARP or NDP requests on behalf of a target host if the target host is know= n to ONOS (i.e. it is present and active in the Host store). ProxyARP consi= ders the network to be a single IP network, therefore if it receives a requ= est for which the target host is not known, it will flood the request out e= very edge port in the network (apart from the input port) in the hope that = the host exists in the network and will reply.
There is a CLI command that allows users to view the neighbour handler r=
egistrations that are held by the service. The CLI command is =E2=80=98