| | 556 | ==== w/o 3/10-3/15 ==== #w24 |
| | 557 | '''Route setup/capabilities advertisement.''' |
| | 558 | |
| | 559 | Controllers inform one another of the services that they provide to the control plane. This information is conveyed in the form of a unique service ID (SID) and a series of network events of interest to the service, which should be forwarded to the service in order for them to be properly handled. Control plane service sets are learned by controllers via messages exchanged and propagated across the hierarchy. We construct a message propagation mechanism beginning with the following assumptions: |
| | 560 | |
| | 561 | * since no tier serves a tier above, advertisements only need to move downwards, from high to low tiers. |
| | 562 | * control planes remain small and topologically restricted compared to the data plane. |
| | 563 | * peers do not serve one another e.g. disregard one another's services, as they provide identicalfunctionalities. Therefore advertisements are disregarded among peers. |
| | 564 | |
| | 565 | While the hierarchy restricts the flow of message propagation, measures must be taken to prevent loops, notably within the bidirectional horizontal connections. In addition, multiple routes to a server may exist in the control plane, in which case we wish to choose a shortest path. We employ a message propagation mechanism and path selection mechanism similar to RIP with split horizon: |
| | 566 | |
| | 567 | {{{ |
| | 568 | if message received |
| | 569 | extract hop count, SID |
| | 570 | if SID has already been seen |
| | 571 | if this hop count < old hop count |
| | 572 | discard old next hop |
| | 573 | else |
| | 574 | if message is from peer |
| | 575 | discard message |
| | 576 | else |
| | 577 | record SID and next hop |
| | 578 | for each known adjacency |
| | 579 | if not sender of message |
| | 580 | send to adjacency |
| | 581 | }}} |
| | 582 | |
| | 583 | the first block is the path selection stage, and the second, the forwarding stage. Paths are selected based on hop count, as a simple metric that is meaningful in networks whose links have approximately equal throughput. |
| | 584 | |
| | 585 | ---- |
| | 586 | '''Forwarding table/filtration subsystem.''' |
| | 587 | |
| | 588 | The filter system (forwarding table) pulls up subscribers when events are dispatched. Subscribers are returned by their service IDs, which allows for remapping of Service IDs to next hop, the latter whose mapping to SID is maintained in the route table. This allows for tracking of bot best next hop and event-to-SID mapping despite possibilities of changes in next hop. |
| | 589 | |
| | 590 | The syntax of the filter is simple, only functioning on matching against six items: |
| | 591 | * DPID : as a hex string beginning with '0x' |
| | 592 | * VLAN : a integral value |
| | 593 | * Source/destination Hardware address : six colon-separated hex values '00:00:ab:cd:ef:90' |
| | 594 | * Source/destination IP address : dotted-decimal integers 'x.x.x.x' |
| | 595 | * event trigger item : event type. |
| | 596 | |
| | 597 | Event trigger item refers to the cause of a certain event, e.g. a network host that triggered a new device event. So far, the first five are implemented. The last is a dilemma, as it can become a choke point in concurrency when event triggers are updated or checked frequently. |
| | 598 | |
| | 599 | Items are described as source, destination, or any. source or destination only apply to network and hardware addresses and these specifiers are ignored for DPID and VLAN. 'any' is a wildcard that matches on either source or destination, and is a default for DPID and VLAN. |
| | 600 | |
| | 601 | In addition to sending the event to a next hop to the service ID, a packet process chain action (PPC) is applied to the manner in which the controller behaves. This component is essentially firewall-like, however with four operations: |
| | 602 | |
| | 603 | * ALLOW : process packet as normal |
| | 604 | * DENY : send back a drop message, blocking the packet |
| | 605 | * SPLIT : send copy of the packet upstream to SID, at the same time allowing process of message locally |
| | 606 | * DIVERT : send copy upstream, however cease processing locally until results are returned. |
| | 607 | |
| | 608 | When two service IDs for the same event return a different PPC, the PPCs are consolidated with this precedence order: |
| | 609 | {{{ |
| | 610 | allow < [deny|split] < divert |
| | 611 | }}} |
| | 612 | with deny and split being combined into a divert action. This choice for precedence and priority handling is acceptable as long as we stand by the assumption that no two servers provide overlapping rules. For example, no service will absolutely rely upon a event being ALLOWed when another service relies on DIVERTing it, in which case, conflicts in handling will result in control plane malfunction. |
| | 613 | |
| | 614 | |
