Well-Known Services 1. Definition A Well-Known Service (WKS) is a service that has a clear and precise definition about what performance guarantees a domain offers or expects to receive when negotiating an SLS. A WKS must present the same behaviour in all domains implementing it (although its implementation may differ), so that it is possible to deploy an end to end service to the end-users. Domains specify the desired well-known service in the SLS during the negotiation by way of an identifier (ID). This ID doesn’t need to be global though. It may have a local value, through a pre-negotiation between a peer (or group) of domains. 2. Motivation There are some reasons for creating Well-Known Services. The most important one is the impossibility (or extreme difficulty) for a domain to capture the semantics of a service and all the implications on its implementation just by observing some performance parameters in the SLS during the negotiation process. WKSs help the development of all activities related to the deployment of a new service, like network planning, resource provisioning and traffic engineering. In some cases, even the network topology may affect the guarantees offered to a service and a domain implementing such a service should be aware of this kind of influence. For example, although the difference between specifying a deterministic service and a predictive service may be a percentile for delay and jitter, they demand a different implementation in terms of resource provisioning, admission control, etc. The choice and combination of performance parameters necessary to describe a service may lead to different ways of configuring the network. For example: throughput and delay; throughput and jitter; throughput, delay and jitter; throughput, delay and packet loss, etc. In addition, the parameters themselves may have different interpretations for different services. For example, an end to end Virtual Wire Service, based on Virtual Wire PDB, could think of jitter as being "phase jitter" (like the VW PDB definition) contrary to the most common definition of "interarrival jitter". Of course it is possible to present precise definitions of all performance parameters in the SLS specification in order to avoid ambiguities. However, it is likely that some services could not function properly as they were originally conceived because of this lack of flexibility. Furthermore, if a service can be undoubtedly well understood by a domain during an SLS negotiation just by observing parameters, then actually there is only one type of service, that may be parameterized to create different instances of it. This service should satisfy all possible variations that end users and other domains could ever desire, over a single network implementation. IntServ services are formally defined (by RFCs) and identified by IDs (service_names). The two services defined by the work group, Guaranteed Quality of Service and Controlled Load, are indeed different. If both were considered variations of a same service, the work group probably would have created one base service, with parameters to differentiate them. It may be difficult (if not impossible, in some cases) to capture the semantics of a service only by the QoS parameters. For example, Controlled Load service states that: "the transit delay experienced by a very high percentage of the delivered packets will not greatly exceed the minimum transmit delay experienced by any successfully delivered packet" (RFC 2211, section 2). Of course, it would always be possible to change this definition for a quantitative one, like: "99,5 % of the packets will experience a maximum delay of 100 ms". Another option would be a qualitative definition: "most packets will experience low delay". Both definitions try to approximate the service to fit in an established SLS format, but they not necessarily catch the original service semantics. In some other cases, the SLS negotiation process may become quite complex to capture the desired service semantics. For example, a client could ask the network for the lowest possible delay, instead of specifying the maximum accepted delay. In order to get such a service, one could define an SLS format and create a more complex negotiation protocol (or another mechanism). However, it implies a trade-off between flexibility in service creation and specification and simplicity in the negotiation. Another simple solution would be prohibit this kind of service. The use of WKS may resolve the above problems. They are a way of specifying a single behaviour for an end to end service, distinguishing services semantically different that may demand different implementations. However, a WKS itself is independent of the implementation mechanisms adopted in a particular domain. 3. Transport and Customer Services The need for WKSs is different for services between domains (called here "Transport Services") and services offered to end-users (called "Customer Services"). Transport Services make up the infrastructure needed for deploying end to end services and they are implemented and negotiated by domains (different types of providers). It means that they are not the kind of service offered to the end-user. The motivation above refers to this kind of Transport Services. Customer services are those that make sense for the end-user (business or home users) and are directly related to the network utilization demand they (users) have (Internet Telephony, for example). Providers must map Customer Services into Transport Services in order to deploy them. WKSs could also be used for specifying Customer Services, but with a different meaning. Customer WKSs could be a way for a provider to organize its service offerings and simplify the mapping to Transport Services. 4. Transport Service Classes Instead of attempting to define all possible Transport Services as WKSs, a better way is to group them in some classes encompassing semantically similar services, and from these classes new services can be instantiated through careful parameter configuration. A service class should be defined in a formal document and each domain that declares to offer services based on this class must be able to implement it correctly. The required information to specify a class are: - Explanation of the service semantics in a human language. - Mathematical proof, depending on the class. - Configurable performance parameters, along with its definition (like jitter, that has some different definitions) - An identifier (ID), not necessarily global. It may be suggested, but its adoption is not compulsory (like the DSCP). Any peer (or group) of domains may establishes its own preferable ID for a service class. - Other information (to be defined) The SLS should have a unique format for all classes, in order to avoid unnecessary complexity. If a client requests a service class it knows beforehand the provider is able to deploy he/she has a guarantee that the end to end service semantics will be preserved. Within each class, services can be dynamically instantiated through parameter negotiation. Providers can, optionally, create permanent instances of WKSs (with their own IDs) using the class ID and specifying pre-defined values for some parameters. However, this is just a way of organizing services and simplifying the negotiation through SLSs. 5. Examples of Well-Known Service Classes Initially a very small number of Transport WKS Classes should be defined, since providers should be able to map several customer service into a few transport services. Non-adaptive services (quantitative ?) Class 1: Guaranteed Service Class 2: Predictive Service Adaptive services (qualitative ?) Class 3: Better than Best Effort Class 4: Best Effort (these services must be better defined)