Previous

Content

Next 

1.0.- Q.OSPF - Overall Framework  

The network will support both best-effort and QoS guarantees packets. The assumption is that each router in the network is able to dedicate some of its resources to satisfy the requirements of QoS packets. All routers must support the QoS Extension. Flows are unicast.
Flows with QoS requirements specifies them in some fashion that is accessible to the routing protocol, for example, this could correspond to the arrival of an RSVP PATH message, whose TSpec is passed to the routing protocol together with the destination address.
After processing such a request, the protocol will return the path that it deems the most suitable given the flow's requirements. The returned path could be the best next hop, i.e., a hop-by-hop path selection model, or all intermediate nodes to the destination, i.e., an explicit route model. The model currently supported for this specification will be the hop-by-hop path selection model.
  The mechanism described in this document are at the control plane level and will be independent of the data plane mechanism, such as the packet classification method used. However, QoS guarantees stability of the data plane. In particular, while it is possible that after a path is first selected, network conditions change and result in the appearence of better paths, such changes should be prevented from unnecessarely affecting existing paths. Then, switching over to a new and better path should be limited to those conditions where initial selection turns out to be inadequate or extremely expensive.
State information should be maintained for each QoS path after it has been selected. This information is used to track the validity of the selected path. A path is pinned when its state specifies that a new QoS routing query is not required, and un-pinned otherwise. Pinning and un-pinning of paths should be coordinated with RSVP soft states, and structured so as to require minimal changes to RSVP processing rules.
Previous

Content

Next