network will satisfy the service requestthat there are no guarantees associated

Network will satisfy the service requestthat there

This preview shows page 49 - 54 out of 74 pages.

. 52
Service Characteristics (Cont…) Service Offerings Service requests that are generated by users, applications, or devices are supported by services offered by the network. These service offerings (e.g., via frame relay CIR or IP ToS or QoS) are the network counterparts to user, application, and device requests for service. Service offerings map to service requests and thus can also be categorized as best effort, predictable, or guaranteed. 53
Service Characteristics (Cont…) Best-effort service offerings are not predictable — they are based on the state of the network at any given time. There is little or no prior knowledge about available performance, and there is no control over the network at any time. Most networks today operate in best-effort mode. An example of a best-effort service request and offering is a file transfer (e.g., using FTP) over the Internet. FTP uses TCP as its transport protocol, which adapts, via a sliding window flow-control mechanism , to approximate the current state of the network it is operating across. In addition, as part of TCP’s service to the applications it supports, it provides error- free , reliable data transmission. 54
Service Characteristics (Cont…) Predictable and guaranteed service offerings should be compatible with their corresponding service requests. Service performance requirements (capacity, delay, and RMA) in a service request are translated into the corresponding performance characteristics in the service offering. 55
Service Characteristics (Cont…) Example 1.10: An example of a predictable service request and offering can be seen in a network designed to support real-time streams of telemetry data . An architectural/design goal for a network supporting real-time telemetry is the ability to specify end-to-end delay and have the network satisfy this delay request. A real-time telemetry stream should have an end-to-end delay requirement, and this requirement would form the basis for the service request. For example , this service request may be for an end-to-end delay of 25 ms, with a delay variation of ±400 s. This would form the request and the service level (i.e., a QoS level) that needs to be supported by the network. The network would then be architected and designed to support a QoS level of 25 ms end-to-end delay and a delay variation of ±400 s.

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture