Network Working Group J. Babiarz Request for Comments: 4594 K. Chan Category: Informational Nortel Networks F. Baker Cisco Systems August 2006 Configuration Guidelines for DiffServ Service Classes
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using
Differentiated Services Code Points (DSCPs), traffic conditioners,
Per-Hop Behaviors (PHBs), and Active Queue Management (AQM)
mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service
class, but as a policy and for interoperability it is useful to apply them consistently.
Babiarz, et al. Informational [Page 1]
Table of Contents
1. Introduction (3)
1.1. Requirements Notation (4)
1.2. Expected Use in the Network (4)
1.3. Service Class Definition (5)
1.4. Key Differentiated Services Concepts (5)
1.4.1. Queuing (6)
1.4.1.1. Priority Queuing (6)
1.4.1.2. Rate Queuing (6)
1.4.2. Active Queue Management (7)
1.4.3. Traffic Conditioning (7)
1.4.4. Differentiated Services Code Point (DSCP) (8)
1.4.5. Per-Hop Behavior (PHB) (8)
1.5. Key Service Concepts (8)
1.5.1. Default Forwarding (DF) (9)
1.5.2. Assured Forwarding (AF) (9)
1.5.3. Expedited Forwarding (EF) (10)
1.5.4. Class Selector (CS) (10)
1.5.5. Admission Control (11)
2. Service Differentiation (11)
2.1. Service Classes (12)
2.2. Categorization of User Service Classes (13)
2.3. Service Class Characteristics (16)
2.4. Deployment Scenarios (21)
2.4.1. Example 1 (21)
2.4.2. Example 2 (23)
2.4.3. Example 3 (25)
3. Network Control Traffic (27)
3.1. Current Practice in the Internet (27)
3.2. Network Control Service Class (27)
3.3. OAM Service Class (29)
4. User Traffic (30)
4.1. Telephony Service Class (31)
4.2. Signaling Service Class (33)
4.3. Multimedia Conferencing Service Class (35)
4.4. Real-Time Interactive Service Class (37)
4.5. Multimedia Streaming Service Class (39)
4.6. Broadcast Video Service Class (41)
4.7. Low-Latency Data Service Class (43)
4.8. High-Throughput Data Service Class (45)
4.9. Standard Service Class (47)
4.10. Low-Priority Data (48)
5. Additional Information on Service Class Usage (49)
5.1. Mapping for Signaling (49)
5.2. Mapping for NTP (50)
5.3. VPN Service Mapping (50)
6. Security Considerations (51)
Babiarz, et al. Informational [Page 2]
7. Acknowledgements (52)
8. Appendix A (53)
8.1. Explanation of Ring Clipping (53)
9. References (54)
9.1. Normative References (54)
9.2. Informative References (55)
1. Introduction
To aid in understanding the role of this document, we use an analogy: the Differentiated Services specifications are fundamentally a
toolkit. The specifications provide the equivalent of band saws,
planers, drill presses, and other tools. In the hands of an expert, there is no limit to what can be built, but such a toolkit can be
intimidating to the point of being inaccessible to a non-expert who
just wants to build a bookcase. This document should be viewed as a set of "project plans" for building all the (diffserv) furniture that one might want. The user may choose what to build (e.g., perhaps our non-expert doesn’t need a china cabinet right now), and how to go
about building it (e.g., plans for a non-expert probably won’t employ mortise/tenon construction, but that absence does not imply that
mortise/tenon construction is forbidden or unsound). The authors
hope that these diffserv "project plans" will provide a useful guide to Network Administrators in the use of diffserv techniques to
implement quality-of-service measures appropriate for their network’s traffic.
This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using
Differentiated Services Code Points (DSCPs), traffic conditioners,
Per-Hop Behaviors (PHBs), and Active Queue Management (AQM)
mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service
class, but as a policy and for interoperability it is useful to apply them consistently.
Service class definitions are based on the different traffic
characteristics and required performance of the
applications/services. This approach allows us to map current and
future applications/services of similar traffic characteristics and
performance requirements into the same service class. Since the
applications’/services’ characteristics and required performance are end to end, the service class notion needs to be preserved end to
end. With this approach, a limited set of service classes is
required. For completeness, we have defined twelve different service classes, two for network operation/administration and ten for
user/subscriber applications/services. However, we expect that
network administrators will implement a subset of these classes Babiarz, et al. Informational [Page 3]
relevant to their customers and their service offerings. Network
Administrators may also find it of value to add locally defined
service classes, although these will not necessarily enjoy end-to-end properties of the same type.
Section 1 provides an introduction and overview of technologies that are used for service differentiation in IP networks. Section 2 is an overview of how service classes are constructed to provide service
differentiation, with examples of deployment scenarios. Section 3
provides configuration guidelines of service classes that are used
for stable operation and administration of the network. Section 4
provides configuration guidelines of service classes that are used
for differentiation of user/subscriber traffic. Section 5 provides
additional guidance on mapping different applications/protocols to
service classes. Section 6 addresses security considerations.
1.1. Requirements Notation
The key words "SHOULD", "SHOULD NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
1.2. Expected Use in the Network
In the Internet today, corporate LANs and ISP WANs are generally not heavily utilized. They are commonly 10% utilized at most. For this reason, congestion, loss, and variation in delay within corporate
LANs and ISP backbones is virtually unknown. This clashes with user perceptions, for three very good reasons.
o The industry moves through cycles of bandwidth boom and bandwidth bust, depending on prevailing market conditions and the periodic
deployment of new bandwidth-hungry applications.
o In access networks, the state is often different. This may be
because throughput rates are artificially limited or over-
subscribed, or because of access network design trade-offs.
o Other characteristics, such as database design on web servers
(that may create contention points, e.g., in filestore) and
configuration of firewalls and routers, often look externally like a bandwidth limitation.
The intent of this document is to provide a consistent marking,
conditioning, and packet treatment strategy so that it can be
configured and put into service on any link that is itself congested. Babiarz, et al. Informational [Page 4]
1.3. Service Class Definition
A "service class" represents a set of traffic that requires specific delay, loss, and jitter characteristics from the network.
Conceptually, a service class pertains to applications with similar
characteristics and performance requirements, such as a "High-
Throughput Data" service class for applications like the web and
electronic mail, or a "Telephony" service class for real-time traffic such as voice and other telephony services. Such a service class may be defined locally in a Differentiated Services (DS) domain, or
across multiple DS domains, possibly extending end to end.
A service class as defined here is essentially a statement of the
required characteristics of a traffic aggregate. The required
characteristics of these traffic aggregates can be realized by the
use of defined per-hop behavior (PHB) [RFC2474]. The actual
specification of the expected treatment of a traffic aggregate within a domain may also be defined as a per-domain behavior (PDB)
[RFC3086].
Each domain may choose to implement different service classes or to
use different behaviors to implement the service classes or to
aggregate different kinds of traffic into the aggregates and still
achieve their required characteristics. For example, low delay,
loss, and jitter may be realized using the EF PHB, or with an over-
provisioned AF PHB. This must be done with care as it may disrupt
the end-to-end performance required by the applications/services.
This document provides recommendations on usage of PHBs for specific service classes for their consistent implementation. These
recommendations are not to be construed as prohibiting use of other
PHBs that realize behaviors sufficient for the relevant class of
traffic.
The Default Forwarding "Standard" service class is REQUIRED; all
other service classes are OPTIONAL. It is expected that network
administrators will base their choice of the level of service
differentiation that they will support on their need, starting off
with three or four service classes for user traffic and adding others as the need arises.
1.4. Key Differentiated Services Concepts
The reader SHOULD be familiar with the principles of the
Differentiated Services Architecture [RFC2474]. We recapitulate key concepts here only to provide convenience for the reader, the
referenced RFCs providing the authoritative definitions.
Babiarz, et al. Informational [Page 5]
1.4.1. Queuing
A queue is a data structure that holds packets that are awaiting
transmission. The packets may be delayed while in the queue,
possibly due to lack of bandwidth, or because it is low in priority. There are a number of ways to implement a queue. A simple model of a queuing system, however, is a set of data structures for packet data, which we will call queues, and a mechanism for selecting the next
packet from among them, which we call a scheduler.
1.4.1.1. Priority Queuing
A priority queuing system is a combination of a set of queues and a
scheduler that empties them in priority sequence. When asked for a
packet, the scheduler inspects the highest priority queue and, if
there is data present, returns a packet from that queue. Failing
that, it inspects the next highest priority queue, and so on. A
freeway onramp with a stoplight for one lane that allows vehicles in the high-occupancy-vehicle lane to pass is an example of a priority
queuing system; the high-occupancy-vehicle lane represents the
"queue" having priority.
In a priority queuing system, a packet in the highest priority queue will experience a readily calculated delay. This is proportional to the amount of data remaining to be serialized when the packet arrived plus the volume of the data already queued ahead of it in the same
queue. The technical reason for using a priority queue relates
exactly to this fact: it limits delay and variations in delay and
should be used for traffic that has that requirement.
A priority queue or queuing system needs to avoid starvation of
lower-priority queues. This may be achieved through a variety of
means, such as admission control, rate control, or network
engineering.
1.4.1.
2. Rate Queuing
Similarly, a rate-based queuing system is a combination of a set of
queues and a scheduler that empties each at a specified rate. An
example of a rate-based queuing system is a road intersection with a stoplight. The stoplight acts as a scheduler, giving each lane a
certain opportunity to pass traffic through the intersection.
In a rate-based queuing system, such as Weighted Fair Queuing (WFQ)
or Weighted Round Robin (WRR), the delay that a packet in any given
queue will experience depends on the parameters and occupancy of its queue and the parameters and occupancy of the queues it is competing with. A queue whose traffic arrival rate is much less than the rate Babiarz, et al. Informational [Page 6]
at which it lets traffic depart will tend to be empty, and packets in it will experience nominal delays. A queue whose traffic arrival
rate approximates or exceeds its departure rate will tend not to be
empty, and packets in it will experience greater delay. Such a
scheduler can impose a minimum rate, a maximum rate, or both, on any queue it touches.
1.4.
2. Active Queue Management
Active Queue Management, or AQM, is a generic name for any of a
variety of procedures that use packet dropping or marking to manage
the depth of a queue. The canonical example of such a procedure is
Random Early Detection (RED), in that a queue is assigned a minimum
and maximum threshold, and the queuing algorithm maintains a moving
average of the queue depth. While the mean queue depth exceeds the
maximum threshold, all arriving traffic is dropped. While the mean
queue depth exceeds the minimum threshold but not the maximum
threshold, a randomly selected subset of arriving traffic is marked
or dropped. This marking or dropping of traffic is intended to
communicate with the sending system, causing its congestion avoidance algorithms to kick in. As a result of this behavior, it is
reasonable to expect that TCP’s cyclic behavior is desynchronized and that the mean queue depth (and therefore delay) should normally
approximate the minimum threshold.
A variation of the algorithm is applied in Assured Forwarding PHB
[RFC2597], in that the behavior aggregate consists of traffic with
multiple DSCP marks, which are intermingled in a common queue.
Different minima and maxima are configured for the several DSCPs
separately, such that traffic that exceeds a stated rate at ingress
is more likely to be dropped or marked than traffic that is within
its contracted rate.
1.4.3. Traffic Conditioning
In addition, at the first router in a network that a packet crosses, arriving traffic may be measured and dropped or marked according to a policy, or perhaps shaped on network ingress, as in "A Rate Adaptive Shaper for Differentiated Services" [RFC2963]. This may be used to
bias feedback loops, as is done in "Assured Forwarding PHB"
[RFC2597], or to limit the amount of traffic in a system, as is done in "Expedited Forwarding PHB" [RFC3246]. Such measurement procedures are collectively referred to as "traffic conditioners". Traffic
conditioners are normally built using token bucket meters, for
example with a committed rate and burst size, as in Section 1.5.3 of the DiffServ Model [RFC3290]. The Assured Forwarding PHB [RFC2597]
uses a variation on a meter with multiple rate and burst size
measurements to test and identify multiple levels of conformance. Babiarz, et al. Informational [Page 7]
Multiple rates and burst sizes can be realized using multiple levels of token buckets or more complex token buckets; these are
implementation details. The following are some traffic conditioners that may be used in deployment of differentiated services:
o For Class Selector (CS) PHBs, a single token bucket meter to
provide a rate plus burst size control.
o For Expedited Forwarding (EF) PHB, a single token bucket meter to provide a rate plus burst size control.
o For Assured Forwarding (AF) PHBs, usually two token bucket meters configured to provide behavior as outlined in "Two Rate Three
Color Marker (trTCM)" [RFC2698] or "Single Rate Three Color Marker (srTCM)" [RFC2697]. The two-rate, three-color marker is used to
enforce two rates, whereas the single-rate, three-color marker is used to enforce a committed rate with two burst lengths.
1.4.4. Differentiated Services Code Point (DSCP)
The DSCP is a number in the range 0..63 that is placed into an IP
packet to mark it according to the class of traffic it belongs in.
Half of these values are earmarked for standardized services, and the other half of them are available for local definition.
1.4.5. Per-Hop Behavior (PHB)
In the end, the mechanisms described above are combined to form a
specified set of characteristics for handling different kinds of
traffic, depending on the needs of the application. This document
seeks to identify useful traffic aggregates and to specify what PHB
should be applied to them.
1.5. Key Service Concepts
While Differentiated Services is a general architecture that may be
used to implement a variety of services, three fundamental forwarding behaviors have been defined and characterized for general use. These are basic Default Forwarding (DF) behavior for elastic traffic, the
Assured Forwarding (AF) behavior, and the Expedited Forwarding (EF)
behavior for real-time (inelastic) traffic. The facts that four code points are recommended for AF and that one code point is recommended for EF are arbitrary choices, and the architecture allows any
reasonable number of AF and EF classes simultaneously. The choice of four AF classes and one EF class in the current document is also
arbitrary, and operators MAY choose to operate more or fewer of
either.
Babiarz, et al. Informational [Page 8]
The terms "elastic" and "real-time" are defined in [RFC1633], Section 3.1, as a way of understanding broad-brush application requirements. This document should be reviewed to obtain a broad understanding of
the issues in quality of service, just as [RFC2475] should be
reviewed to understand the data plane architecture used in today’s
Internet.
1.5.1. Default Forwarding (DF)
The basic forwarding behaviors applied to any class of traffic are
those described in [RFC2474] and [RFC2309]. Best-effort service may be summarized as "I will accept your packets" and is typically
configured with some bandwidth guarantee. Packets in transit may be lost, reordered, duplicated, or delayed at random. Generally,
networks are engineered to limit this behavior, but changing traffic loads can push any network into such a state.
Application traffic in the internet that uses default forwarding is
expected to be "elastic" in nature. By this, we mean that the sender of traffic will adjust its transmission rate in response to changes
in available rate, loss, or delay.
For the basic best-effort service, a single DSCP value is provided to identify the traffic, a queue to store it, and active queue
management to protect the network from it and to limit delays.
1.5.
2. Assured Forwarding (AF)
The Assured Forwarding PHB [RFC2597] behavior is explicitly modeled
on Frame Relay’s Discard Eligible (DE) flag or ATM’s Cell Loss
Priority (CLP) capability. It is intended for networks that offer
average-rate Service Level Agreements (SLAs) (as FR and ATM networks do). This is an enhanced best-effort service; traffic is expected to be "elastic" in nature. The receiver will detect loss or variation
in delay in the network and provide feedback such that the sender
adjusts its transmission rate to approximate available capacity.
For such behaviors, multiple DSCP values are provided (two or three, perhaps more using local values) to identify the traffic, a common
queue to store the aggregate, and active queue management to protect the network from it and to limit delays. Traffic is metered as it
enters the network, and traffic is variously marked depending on the arrival rate of the aggregate. The premise is that it is normal for users occasionally to use more capacity than their contract
stipulates, perhaps up to some bound. However, if traffic should be marked or lost to manage the queue, this excess traffic will be
marked or lost first.
Babiarz, et al. Informational [Page 9]
1.5.3. Expedited Forwarding (EF)
The intent of Expedited Forwarding PHB [RFC3246] is to provide a
building block for low-loss, low-delay, and low-jitter services. It can be used to build an enhanced best-effort service: traffic remains subject to loss due to line errors and reordering during routing
changes. However, using queuing techniques, the probability of delay or variation in delay is minimized. For this reason, it is generally used to carry voice and for transport of data information that
requires "wire like" behavior through the IP network. Voice is an
inelastic "real-time" application that sends packets at the rate the codec produces them, regardless of availability of capacity. As
such, this service has the potential to disrupt or congest a network if not controlled. It also has the potential for abuse.
To protect the network, at minimum one SHOULD police traffic at
various points to ensure that the design of a queue is not overrun,
and then the traffic SHOULD be given a low-delay queue (often using
priority, although it is asserted that a rate-based queue can do
this) to ensure that variation in delay is not an issue, to meet
application needs.
1.5.4. Class Selector (CS)
Class Selector provides support for historical codepoint definitions and PHB requirement. The Class Selector DS field provides a limited backward compatibility with legacy (pre DiffServ) practice, as
described in [RFC2474], Section 4. Backward compatibility is
addressed in two ways. First, there are per-hop behaviors that are
already in widespread use (e.g., those satisfying the IPv4 Precedence queuing requirements specified in [RFC1812]), and we wish to permit
their continued use in DS-compliant networks. In addition, there are some codepoints that correspond to historical use of the IP
Precedence field, and we reserve these codepoints to map to PHBs that meet the general requirements specified in [RFC2474], Section
4.2.2.2.
No attempt is made to maintain backward compatibility with the "DTR" or Type of Service (TOS) bits of the IPv4 TOS octet, as defined in
[RFC0791] and [RFC1349].
A DS-compliant network can be deployed with a set of one or more
Class Selector-compliant PHB groups. Also, a network administrator
may configure the network nodes to map codepoints to PHBs,
irrespective of bits 3-5 of the DSCP field, to yield a network that
is compatible with historical IP Precedence use. Thus, for example, codepoint ’011000’ would map to the same PHB as codepoint ’011010’. Babiarz, et al. Informational [Page 10]
1.5.5. Admission Control
Admission control (including refusal when policy thresholds are
crossed) can ensure high-quality communication by ensuring the
availability of bandwidth to carry a load. Inelastic real-time flows such as Voice over Internet Protocol (VoIP) (telephony) or video
conferencing services can benefit from use of an admission control
mechanism, as generally the telephony service is configured with
over-subscription, meaning that some users may not be able to make a call during peak periods.
For VoIP (telephony) service, a common approach is to use signaling
protocols such as SIP, H.323, H.248, MEGACO, and Resource Reservation Protocol (RSVP) to negotiate admittance and use of network transport capabilities. When a user has been authorized to send voice traffic, this admission procedure has verified that data rates will be within the capacity of the network that it will use. Many RTP voice
payloads are inelastic and cannot react to loss or delay in any
substantive way. For these voice payloads, the network SHOULD police at ingress to ensure that the voice traffic stays within its
negotiated bounds. Having thus assured a predictable input rate, the network may use a priority queue to ensure nominal delay and
variation in delay.
Another approach that may be used in small and bandwidth-constrained networks for limited number of flows is RSVP [RFC2205] [RFC2996].
However, there is concern with the scalability of this solution in
large networks where aggregation of reservations [RFC3175] is
considered to be required.
2. Service Differentiation
There are practical limits on the level of service differentiation
that should be offered in the IP networks. We believe we have
defined a practical approach in delivering service differentiation by defining different service classes that networks may choose to
support in order to provide the appropriate level of behaviors and
performance needed by current and future applications and services.
The defined structure for providing services allows several
applications having similar traffic characteristics and performance
requirements to be grouped into the same service class. This
approach provides a lot of flexibility in providing the appropriate
level of service differentiation for current and new, yet unknown
applications without introducing significant changes to routers or
network configurations when a new traffic type is added to the
network.
Babiarz, et al. Informational [Page 11]
2.1. Service Classes
Traffic flowing in a network can be classified in many different
ways. We have chosen to divide it into two groupings, network
control and user/subscriber traffic. To provide service
differentiation, different service classes are defined in each
grouping. The network control traffic group can further be divided
into two service classes (see Section 3 for detailed definition of
each service class):
o "Network Control" for routing and network control function.
o "OAM" (Operations, Administration, and Management) for network
configuration and management functions.
The user/subscriber traffic group is broken down into ten service
classes to provide service differentiation for all the different
types of applications/services (see Section 4 for detailed definition of each service class):
o Telephony service class is best suited for applications that
require very low delay variation and are of constant rate, such as IP telephony (VoIP) and circuit emulation over IP applications.
o Signaling service class is best suited for peer-to-peer and
client-server signaling and control functions using protocols such as SIP, SIP-T, H.323, H.248, and Media Gateway Control Protocol
(MGCP).
o Multimedia Conferencing service class is best suited for
applications that require very low delay and have the ability to
change encoding rate (rate adaptive), such as H.323/V2 and later
video conferencing service.
o Real-Time Interactive service class is intended for interactive
variable rate inelastic applications that require low jitter and
loss and very low delay, such as interactive gaming applications
that use RTP/UDP streams for game control commands, and video
conferencing applications that do not have the ability to change
encoding rates or to mark packets with different importance
indications.
o Multimedia Streaming service class is best suited for variable
rate elastic streaming media applications where a human is waiting for output and where the application has the capability to react
to packet loss by reducing its transmission rate, such as
streaming video and audio and webcast.
o Broadcast Video service class is best suited for inelastic
streaming media applications that may be of constant or variable
rate, requiring low jitter and very low packet loss, such as
broadcast TV and live events, video surveillance, and security. Babiarz, et al. Informational [Page 12]
o Low-Latency Data service class is best suited for data processing applications where a human is waiting for output, such as web-
based ordering or an Enterprise Resource Planning (ERP)
application.
o High-Throughput Data service class is best suited for store and
forward applications such as FTP and billing record transfer.
o Standard service class is for traffic that has not been identified as requiring differentiated treatment and is normally referred to as best effort.
o Low-Priority Data service class is intended for packet flows where bandwidth assurance is not required.
2.2. Categorization of User Service Classes
The ten defined user/subscriber service classes listed above can be
grouped into a small number of application categories. For some
application categories, it was felt that more than one service class was needed to provide service differentiation within that category
due to the different traffic characteristic of the applications,
control function, and the required flow behavior. Figure 1 provides a summary of service class grouping into four application categories. Application Control Category
o The Signaling service class is intended to be used to control
applications or user endpoints. Examples of protocols that would use this service class are SIP or H.248 for IP telephone service
and SIP or Internet Group Management Protocol (IGMP) for control
of broadcast TV service to subscribers. Although user signaling
flows have similar performance requirements as Low-Latency Data,
they need to be distinguished and marked with a different DSCP.
The essential distinction is something like "administrative
control and management" of the traffic affected as the protocols
in this class tend to be tied to the media stream/session they
signal and control.
Media-Oriented Category
Due to the vast number of new (in process of being deployed) and
already-in-use media-oriented services in IP networks, five service
classes have been defined.
o Telephony service class is intended for IP telephony (VoIP)
service. It may also be used for other applications that meet the defined traffic characteristics and performance requirements.
o Real-Time Interactive service class is intended for inelastic
video flows from applications such as SIP-based desktop video
conferencing applications and for interactive gaming.
Babiarz, et al. Informational [Page 13]
o Multimedia Conferencing service class is for video conferencing
solutions that have the ability to reduce their transmission rate on detection of congestion. These flows can therefore be
classified as rate adaptive. As currently two types of video
conferencing equipment are used in IP networks (ones that generate inelastic traffic and ones that generate rate-adaptive traffic),
two service class are needed. The Real-Time Interactive service
class should be used for equipment that generates inelastic video flows and the Multimedia Conferencing service class for equipment that generates rate-adaptive video flows.
o Broadcast Video service class is to be used for inelastic traffic flows, which are intended for broadcast TV service and for
transport of live video and audio events.
o Multimedia Streaming service class is to be used for elastic
multimedia traffic flows. This multimedia content is typically
stored before being transmitted. It is also buffered at the
receiving end before being played out. The buffering is
sufficiently large to accommodate any variation in transmission
rate that is encountered in the network. Multimedia entertainment over IP delivery services that are being developed can generate
both elastic and inelastic traffic flows; therefore, two service
classes are defined to address this space, respectively:
Multimedia Streaming and Broadcast Video.
Data Category
The data category is divided into three service classes.
o Low-Latency Data for applications/services that require low delay or latency for bursty but short-lived flows.
o High-Throughput Data for applications/services that require good
throughput for long-lived bursty flows. High Throughput and
Multimedia Steaming are close in their traffic flow
characteristics with High Throughput being a bit more bursty and
not as long-lived as Multimedia Streaming.
o Low-Priority Data for applications or services that can tolerate
short or long interruptions of packet flows. The Low-Priority
Data service class can be viewed as "don’t care" to some degree.
Best-Effort Category
o All traffic that is not differentiated in the network falls into
this category and is mapped into the Standard service class. If a packet is marked with a DSCP value that is not supported in the
network, it SHOULD be forwarded using the Standard service class. Babiarz, et al. Informational [Page 14]
Figure 1, below, provides a grouping of the defined user/subscriber
service classes into four categories, with indications of which ones use an independent flow for signaling or control; type of flow
behavior (elastic, rate adaptive, or inelastic); and the last column provides end user Quality of Service (QoS) rating as defined in ITU-T Recommendation G.1010.
-----------------------------------------------------------------
| Application | Service | Signaled | Flow | G.1010 |
| Categories | Class | | Behavior | Rating |
|-------------+---------------+----------+-----------+------------|
| Application | Signaling | Not | Inelastic | Responsive |
| Control | |applicable| | |
|-------------+---------------+----------+-----------+------------|
| | Telephony | Yes | Inelastic | Interactive|
| |---------------+----------+-----------+------------|
| | Real-Time | Yes | Inelastic | Interactive|
| | Interactive | | | |
| |---------------+----------+-----------+------------|
| Media- | Multimedia | Yes | Rate | Interactive|
| Oriented | Conferencing | | Adaptive | |
| |---------------+----------+-----------+------------|
| |Broadcast Video| Yes | Inelastic | Responsive |
| |---------------+----------+-----------+------------|
| | Multimedia | Yes | Elastic | Timely |
| | Streaming | | | |
|-------------+---------------+----------+-----------+------------|
| | Low-Latency | No | Elastic | Responsive |
| | Data | | | |
| |---------------+----------+-----------+------------|
| Data |High-Throughput| No | Elastic | Timely |
| | Data | | | |
| |---------------+----------+-----------+------------|
| | Low-Priority | No | Elastic |Non-critical|
| | Data | | | |
|-------------+---------------+----------+-----------+------------|
| Best Effort | Standard | Not Specified |Non-critical|
-----------------------------------------------------------------
Figure 1. User/Subscriber Service Classes Grouping
Babiarz, et al. Informational [Page 15]
Here is a short explanation of the end user QoS category as defined
in ITU-T Recommendation G.1010. User traffic is divided into four
different categories, namely, interactive, responsive, timely, and
non-critical. An example of interactive traffic is between two
humans and is most sensitive to delay, loss, and jitter. Another
example of interactive traffic is between two servers where very low delay and loss are needed. Responsive traffic is typically between a human and a server but can also be between two servers. Responsive
traffic is less affected by jitter and can tolerate longer delays
than interactive traffic. Timely traffic is either between servers
or servers and humans and the delay tolerance is significantly longer than responsive traffic. Non-critical traffic is normally between
servers/machines where delivery may be delay for period of time.
2.3. Service Class Characteristics
This document provides guidelines for network administrators in
configuring their network for the level of service differentiation
that is appropriate in their network to meet their QoS needs. It is expected that network operators will configure and provide in their
networks a subset of the defined service classes. Our intent is to
provide guidelines for configuration of Differentiated Services for a wide variety of applications, services, and network configurations.
In addition, network administrators may choose to define and deploy
other service classes in their network.
Figure 2 provides a behavior view for traffic serviced by each
service class. The traffic characteristics column defines the
characteristics and profile of flows serviced, and the tolerance to
loss, delay, and jitter columns define the treatment the flows will
receive. End-to-end quantitative performance requirements may be
obtained from ITU-T Recommendations Y.1541 and Y.1540.
Babiarz, et al. Informational [Page 16]
------------------------------------------------------------------- |Service Class | | Tolerance to | | Name | Traffic Characteristics | Loss |Delay |Jitter| |===============+==============================+======+======+======| | Network |Variable size packets, mostly | | | | | Control |inelastic short messages, but | Low | Low | Yes | | | traffic can also burst (BGP) | | | | |---------------+------------------------------+------+------+------| | | Fixed-size small packets, | Very | Very | Very | | Telephony | constant emission rate, | Low | Low | Low | | | inelastic and low-rate flows | | | | |---------------+------------------------------+------+------+------| | Signaling | Variable size packets, some | Low | Low | Yes | | | what bursty short-lived flows| | | | |---------------+------------------------------+------+------+------| | Multimedia | Variable size packets, | Low | Very | | | Conferencing | constant transmit interval, | - | Low | Low | | |rate adaptive, reacts to loss |Medium| | | |---------------+------------------------------+------+------+------| | Real-Time | RTP/UDP streams, inelastic, | Low | Very | Low | | Interactive | mostly variable rate | | Low | | |---------------+------------------------------+------+------+------| | Multimedia | Variable size packets, |Low - |Medium| Yes | | Streaming | elastic with variable rate |Medium| | | |---------------+------------------------------+------+------+------| | Broadcast | Constant and variable rate, | Very |Medium| Low | | Video | inelastic, non-bursty flows | Low | | | |---------------+------------------------------+------+------+------| | Low-Latency | Variable rate, bursty short- | Low |Low - | Yes | | Data | lived elastic flows | |Medium| | |---------------+------------------------------+------+------+------| | OAM | Variable size packets, | Low |Medium| Yes | | | elastic & inelastic flows | | | | |---------------+------------------------------+------+------+------| |High-Throughput| Variable rate, bursty long- | Low |Medium| Yes | | Data | lived elastic flows | |- High| | |---------------+------------------------------+------+------+------| | Standard | A bit of everything | Not Specified | |---------------+------------------------------+------+------+------| | Low-Priority | Non-real-time and elastic | High | High | Yes | | Data | | | | | ------------------------------------------------------------------- Figure 2. Service Class Characteristics
Babiarz, et al. Informational [Page 17]
Notes for Figure 2: A "Yes" in the jitter-tolerant column implies
that data is buffered in the endpoint and that a moderate level of
network-induced variation in delay will not affect the application.
Applications that use TCP as a transport are generally good examples. Routing protocols and peer-to-peer signaling also fall in this class; although loss can create problems in setting up calls, a moderate
level of jitter merely makes call placement a little less predictable in duration.
Service classes indicate the required traffic forwarding treatment in order to meet user, application, or network expectations. Section 3 defines the service classes that MAY be used for forwarding network
control traffic, and Section 4 defines the service classes that MAY
be used for forwarding user traffic with examples of intended
application types mapped into each service class. Note that the
application types are only examples and are not meant to be all-
inclusive or prescriptive. Also, note that the service class naming or ordering does not imply any priority ordering. They are simply
reference names that are used in this document with associated QoS
behaviors that are optimized for the particular application types
they support. Network administrators MAY choose to assign different service class names to the service classes that they will support.
Figure 3 defines the RECOMMENDED relationship between service classes and DS codepoint assignment with application examples. It is
RECOMMENDED that this relationship be preserved end to end.
Babiarz, et al. Informational [Page 18]
------------------------------------------------------------------
| Service | DSCP | DSCP | Application | | Class Name | Name | Value | Examples | |===============+=========+=============+==========================| |Network Control| CS6 | 110000 | Network routing | |---------------+---------+-------------+--------------------------| | Telephony | EF | 101110 | IP Telephony bearer | |---------------+---------+-------------+--------------------------| | Signaling | CS5 | 101000 | IP Telephony signaling | |---------------+---------+-------------+--------------------------| | Multimedia |AF41,AF42|100010,100100| H.323/V2 video | | Conferencing | AF43 | 100110 | conferencing (adaptive) | |---------------+---------+-------------+--------------------------| | Real-Time | CS4 | 100000 | Video conferencing and | | Interactive | | | Interactive gaming | |---------------+---------+-------------+--------------------------| | Multimedia |AF31,AF32|011010,011100| Streaming video and | | Streaming | AF33 | 011110 | audio on demand | |---------------+---------+-------------+--------------------------| |Broadcast Video| CS3 | 011000 |Broadcast TV & live events| |---------------+---------+-------------+--------------------------| | Low-Latency |AF21,AF22|010010,010100|Client/server transactions| | Data | AF23 | 010110 | Web-based ordering | |---------------+---------+-------------+--------------------------| | OAM | CS2 | 010000 | OAM&P | |---------------+---------+-------------+--------------------------| |High-Throughput|AF11,AF12|001010,001100| Store and forward | | Data | AF13 | 001110 | applications | |---------------+---------+-------------+--------------------------| | Standard | DF (CS0)| 000000 | Undifferentiated | | | | | applications | |---------------+---------+-------------+--------------------------| | Low-Priority | CS1 | 001000 | Any flow that has no BW | | Data | | | assurance | ------------------------------------------------------------------
Figure 3. DSCP to Service Class Mapping
Notes for Figure 3: Default Forwarding (DF) and Class Selector 0
(CS0) provide equivalent behavior and use the same DS codepoint,
’000000’.
It is expected that network administrators will base their choice of the service classes that they will support on their need, starting
off with three or four service classes for user traffic and adding
others as the need arises.
Babiarz, et al. Informational [Page 19]
Figure 4 provides a summary of DiffServ QoS mechanisms that SHOULD be used for the defined service classes that are further detailed in
Sections 3 and 4 of this document. According to what
applications/services need to be differentiated, network
administrators can choose the service class(es) that need to be
supported in their network.
------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | Queuing| AQM| | Class | | DS Edge | Used | | | |===============+======+===================+=========+========+====| |Network Control| CS6 | See Section 3.1 | RFC2474 | Rate | Yes| |---------------+------+-------------------+---------+--------+----| | Telephony | EF |Police using sr+bs | RFC3246 |Priority| No | |---------------+------+-------------------+---------+--------+----| | Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No | |---------------+------+-------------------+---------+--------+----| | Multimedia | AF41 | Using two-rate, | | | Yes| | Conferencing | AF42 |three-color marker | RFC2597 | Rate | per| | | AF43 | (such as RFC 2698)| | |DSCP| |---------------+------+-------------------+---------+--------+----| | Real-Time | CS4 |Police using sr+bs | RFC2474 | Rate | No | | Interactive | | | | | | |---------------+------+-------------------+---------|--------+----| | Multimedia | AF31 | Using two-rate, | | | Yes| | Streaming | AF32 |three-color marker | RFC2597 | Rate | per| | | AF33 | (such as RFC 2698)| | |DSCP| |---------------+------+-------------------+---------+--------+----| |Broadcast Video| CS3 |Police using sr+bs | RFC2474 | Rate | No | |---------------+------+-------------------+---------+--------+----| | Low- | AF21 | Using single-rate,| | | Yes| | Latency | AF22 |three-color marker | RFC2597 | Rate | per| | Data | AF23 | (such as RFC 2697)| | |DSCP| |---------------+------+-------------------+---------+--------+----| | OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes| |---------------+------+-------------------+---------+--------+----| | High- | AF11 | Using two-rate, | | | Yes| | Throughput | AF12 |three-color marker | RFC2597 | Rate | per| | Data | AF13 | (such as RFC 2698)| | |DSCP| |---------------+------+-------------------+---------+--------+----| | Standard | DF | Not applicable | RFC2474 | Rate | Yes| |---------------+------+-------------------+---------+--------+----| | Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes| | Data | | | | | | ------------------------------------------------------------------
Figure 4. Summary of QoS Mechanisms Used for Each Service Class Babiarz, et al. Informational [Page 20]
前厅部基本业务术语释义 相邻房Adjoining room 即指相邻而不相通的客房，此类房间较适于安排相互熟悉的宾客，而不宜安排不同类型或敌对的宾客。 预付押金Advanced deposit 指宾客在预订客房时所交纳的押金。它对酒店和宾客双方都有益。通常，宾客采用现金、信用卡或酒店签订商务合同的方式预付押金。 抵店时间Arrival time 指宾客抵达酒店的时间，掌握客人的抵店时间，有利于排房、控制房间及提高对客服务质量。 平均房价Average room rate 它是衡量酒店经营效益的标准之一。其计算方法为：酒店客房总收入除以总住客房数。影响平均房价的因素有：所销售的客房种类、免费房数、折扣等。在客房数有限的情况下，提高平均房价有利于增加总收入。 预订提前期Booking lead time 指客人订房日期与到达日期之间的天数，亦称订房提前量。通常，一般散客订房的数量较少，提前期较短，而团体订房的数量较多，而提前期较长。总台掌握各类客人的订房提前期有利于做好预测和销售客房的工作。 取消预订Cancellation 指客人取消预定。取消预定的原因因客人而异，酒店应了解客人取消原因，并且应方便客人取消，客人提前通知酒店取消订房，有利于客房的再次销售。
办理入住登记手续Check in 指客人办理入住登记手续。散客和团体的入住登记步骤不同。 办理结账离店手续Check out 指客人办理结账离店手续。散客和团体的结账离店步骤不同。 确认类订房Confirmed reservation 指酒店对客人的订房要求予以接受的答复。确认的方式分为口头和书面两种，其内容包括：客人的个人情况，住宿要求（抵店日期、离店日期、订房种类、订房数量）以及房价、付款方式和注意事项（保留房的时间等）。 交叉培训Cross training 指员工到其他与本岗位相关的岗位接受培训。如总台员工参加客房的专业培训，客房员工参与总台的专业培训等。此做法便于员工了解相关岗位的工作，从而加深对本职工作的全面认识和提高业务水平。 投诉Complain 指客人对酒店的服务不满而产生抱怨，向酒店提出意见。酒店应认真处理客人投诉，设法进行补救，消除客人怨气，并根据所反映的问题，对服务和管理进行整改。 相连房Connecting room 指相邻且相通的客房。此类房间适于安排关系密切及需互相照顾的客人（如家庭），而不宜安排不同或敌对的客人。 商务房价Commercial rate 指酒店为争取更多的商务客人而一些公司签订合同，给予他们优惠的房间价格，并为享有商务房价的客人提供针对性服务，同时应做好统计工作，检查
前厅部的管理制度和服务规 为了加强与规前厅管理，切实把前厅服务提升到一个新的水平，各项工作能顺利进行，充分体现奖罚分明的原则，制定制度如下： 1、诚实是员工必须遵守的道德规，以诚实的态度对待工作是每位同事必须遵守的规章制度; 2、同事之间团结协作、互相尊重、谅解是搞好一切工作的基础; 3、以工作为重、按时、按质、按量完成工作任务是每位同事应尽的职责 4、牢记酒店的服务宗旨，以及服务准则，虚心学习，开拓进取。 5、严禁泄露酒店商业。 一、前厅部员工基本礼貌用语 1、员工在酒店任何地方碰见客人都应主动跟客人打招呼说：“您好!”或点头微笑致意。 2、门迎、前厅接待人员应在客人到达第一时间向客人致欢迎语：“欢迎光临”，在客人离店时致告别语：“您走好，欢迎下次光临”， 3、任何员工对客人的询问都是第一责任人，有义务耐心为客人解答，使用礼貌用语。若因语气生硬引起客人投诉，取消本月休假2天及全部奖金。 4、结账后、预订后、送行时必须使用邀请用语：“您走好，欢迎下次再来”、“期待您的光临”等。 三、考勤制度
凡已到上班时间，本人还未到岗位时即视为迟到;凡未到下班时间，提前离岗下班即为早退。如员工点到后没按规定时间到达指定工作岗位，同样视为迟到。具体实施细则如下： 1、签到、点到，每迟到、早退累计2次超过30分钟，扣本月休假半天，并处以口头警告，如及时上班且表现良好者可加班加点补回。超过1小时扣本月休假1天，未及时上班视为无故旷工1天，扣除3天工资;无故旷工2天以上(含2天)严重警告，并取消本月全部休假及奖金;无故旷工3天以上(含3天)态度恶劣且无适当理由者，予以辞退并处罚金200元。 2、事假须提前一天通知部门并说明原因，经主管以上管理人员批准后方可休假; 3、不得私自调班，如果确有需要必须事前申请，每人每月调班不得超过3次，如果私自调换班，一经发现取消当时人双方各自本月休假1天及本月全勤奖; 4、严禁代人签到、请假，如发现代入签到者，取消当事人双方各自的本月全部休假及奖金。 四、工作交接制度 1、严格按照酒店交接班制度执行。 2、遵守劳动纪律，提前5-10分钟到岗，检查设备、设施状况是否完好，认真填写、仔细阅读《交接班记录薄》，清楚交接班容，并完善交接签字手续。 3、交班时，不允许口头对接，交接，必须以文字形势记录，认真填写《交接班记录薄》，明确交代下一班将继续完成的工作事项，需记录清楚其容，以便于下一班完成。 4、当班发生的重要事务，必须在《交接班记录薄》上
酒店管理前厅 酒店客房部前厅专用术语 Skipper 1）故意逃帐者； 2）特征是无行李或少行李者，使用假信用卡和假支票者等； 3）预防逃帐的措施有：一是收取足额保证金，二是加强注意。 Pre-assign 1）预先分房。指客人抵达前预先安排所需要的房间。 2）预先分房的重要性表现在提高预订客人入住的效率，减少失误，提高服务质量； 3）预先分房根据客人的要求和酒店的房间状态，如可用房等。 Net rate 1）净房价，指房价中除去佣金、税收、付加费等余下的纯房间收入。 2）一般用于房价表，签写有关房价的合同。 Upgrade 1）将高价格种类的房间按低价格的出售 2）用途：A.用于房间紧张时，给有预订的客人；B.提高接待规格给重要客人。 Room change 1）指为客人转换房间； 2）客人转房有客人方面的要求和酒店方面的请求，应注意转房后相应的变更程序。 Advanced deposit
1）中文意思是：预付订金； 2）其含义是：指客人在订房时所交纳的订金； 3）预付金对酒店和客人双方都有益； 4）收取预付金方式一般有：现金、汇款、信用卡等。 Adjoining room 1）是指相邻房，指相邻而不通的房间； 2）适于安排相互熟识客人 3）不宜安排敌对或不同种类的客人 Connecting room 1）是指相连房，指相邻且相通的房间 2）适于安排关系密切以及需互相照顾的客人 3）不宜安排敌对或不同种类的客人 Pick up service 1)是指接车服务 2)酒店派人和车到车站、机场、码头把客人接回酒店 3)必须明确客人的到达日期、航班车次、时间等资料 4)接客要准时 Guaranteed booking 1）意思是保证订房 2）保证订房对于酒店是最理想的订房 3）遵守合约，任何时候，保证客人的订房 4）如果客人要求的房间已售完，应将高价格的房间降价为普通房价出租
Stock Pitch Worksheet Step 1: Pick a Stock Stick with industries you understand.If you really enjoy shopping, look at retailers. If you’re a Comp Sci major, pitch a software company. This will make your research a lot easier and ultimately you will deliver a better stock pitch. For example, Warren Buffett, arguably the world’s best investor, does not invest in technology companies because they are outside of his sphere of competency. Qualitative approach: Look at the overall economy and choose a sector and industry that you think has particularly positive/negative cyclical or secular themes. Then try to choose the best/worst company in that industry. Quantitative approach: Use arbitrary parameters to filter the overall universe of stocks (e.g. below average P/E, high revenue and earnings growth, high ROE). Yahoo! Finance and MSN Money both offer free stock screeners. Don’t stress over this part of the process. For interviews, the execution is much more important than the idea. As long as you understand your company well and make a compelling argument, you will probably impress your interviewers—regardless of which stock you choose to pitch. Step 2: Craft a Persuasive Pitch There are three basic parts to an effective stock pitch: story, numbers, and valuation. The checklist below should serve as a rough guide as you begin to craft your own stock pitches over winter break. Try to include all of the components I have listed below, but make sure you emphasize those that support your case. And d on’t forget to at least briefly acknowledge risks to your thesis. When delivering your stock pitch, note that it should act as a summary of your research/knowledge of the company. The interviewer will expect more in-depth knowledge/reasoning in the Q&A. You want to be able to have a discussio n, so don’t give it all upfront! Basic Information (example: VistaPrint) Company name: VistaPrint Ticker: VPRT Price: $33 52-week range: $17.55 – $37.75 Note: This is important to know, but a stock’s past returns shouldn’t have any bearing on your decision to buy or sell over an intermediate- to long-term time horizon (i.e. > 6 months). Market cap: $1.4B Recommendation: Buy
目录 接听电话标准 (2) 参观房间流程 (4) 散客预订程序 (5) 入住接待流程 (7) 开门服务流程 (10) 延时退房流程 (11) 挂账操作流程 (12) 客人留言操作流程 (13) 问讯服务处理流程 (14) 客人投诉处理流程 (15) 访客登记操作流程 (17) 贵重物品寄存流程 (18) 租借物品操作流程 (20) 行李寄存操作流程 (21) 物品赔偿操作流程 (22) 商务服务流程 (23) 叫醒服务操作流程 (25) 换房处理流程 (26) 退房结账操作流程 (28) 前厅VIP接待准备工作 (31)
大堂吧服务标准 (32) 接听电话标准 执行人：前台员工 目的：保证及时接听和转接电话，提升客户满意度 标准： 1.接听电话 1）三声铃响内及时接听电话 2）左手拿话筒；右手准备好纸、笔，及时记录有关信息 2. 电话聆听和记录 1)前厅规范用语： 对外：“您好！XX酒为您服务！” 对内：“您好！前台为您服务! 语言清晰，避免使用方言或酒店专业用语，声音亲切、热情、友好，让客人可以听到你的微笑 注：如酒店前台无法区分来电是外线或是内线，则采用对外的规范用语。 2) 耐心聆听客人提问和需求，适时询问来电客人姓名，并用姓氏称呼客人 3) 及时记录有关信息 4) 及时回答客人的询问 3. 转接电话 1) 确认来电者报出的房号、分机号或客人姓名。 2) 来电者要求转接电话至房间时，如只能报出住店客人姓名，前台应快速为客人核实并转接；如只能报出住店客人房号，前台应询问住店客人姓名，核实并转接。 3) 酒店不能将住店客人的信息随意告诉任何人,对于无法报出住店客人的姓名的来电者，要委婉拒绝 4) 及时转接电话 注：前厅部所有员工必须掌握酒店各部门及主要领导电话（包括内线和外线），如需转接至重要领导，一定要先和领导进行确认。 4. 无人应答或占线的处理
前台术语解释：1--30 1、Front office（前厅部） 答：1、指设在饭店前厅销售饭店产品、组织接待工作、调度业务经营和为客人住店提供一系列综合性服务的部门。 2、前厅部的主要任务有两个：一是经营，二是管理。 3、前厅部的组织结构。 2、Front desk（前台或总服务台） 答：1、饭店设置在大堂为客人提供登记、问讯、结账等服务的区域。 2、前台隶属于前厅部。 3、前台是饭店对客服务的窗口。 3、Room status（房间状态） 答：1、一般房间状态分为：住房已清洁（OC）、住房未清洁（OD）、空房已清洁（VC）、空房未清洁（VD）、维修房（OOO）等。 2、清楚地了解房态，有利于为客服务和销售房间。 4、Room type（房间种类） 答：1、常见的房间种类有：标准间（标单、标双）、豪华间、商务房（行政房）、套房（豪华套），相连房和公寓等。 2、不同种类的房间适于不同种类的客人。 5、Double room（双人间） 答：1、指房间里设置一张双人床或两张单人床。 2、双人间的入住对饭店的影响（增加饭店总销售收入）。 6、Signal room（单人间） 答：1、指有一张单人床或一张双人床的房间。 2、入住特点。 7、Suite（套房） 答：1、指有客厅或休息厅和卧室连接在一起的房间。 2、套房的出租有利于提高平均房价，提高客房整体收入。 8、Adjoining room（相邻房） 答：1、指相邻而不相通的房间。 2、适于安排相互熟识客人。 3、不宜安排敌对或不同种类的客人。 9、Reservation（房间预定） 答：1、指饭店为有入住要求的客人所进行的预先安排。 2、预定的内容。 10、Confirmed reservation（确认订房） 答：1、指酒店对客人的预订要求予以接受的答复。 2、确认的方式。 3、确认的内容。 11、Amendment（更改预定） 答：1、指对预定资料进行修正。 2、应注意的事项。 12、Advanced deposit（预付订金） 答：1、指客人在订房时所交纳的订金。
前厅部常用术语英汉对照 （一）酒店各部门、各岗位名称英汉对照 人力资源部Human Resource Division 培训部Training Department 人事部Personnel Department 督导部Quality Inspection Department 财务部Finance and Accounting Division 采购部Purchasing Department 成本部Cost-control Department 电脑部 E.D.P 市场营销部Sales &Marketing Division 公关部Public Relation Department 销售部Sales Department 预订部Reservation Department 客务部Rooms Division 管家部Housekeeping Department 前厅部Front Office Department 餐饮部Food & Beverage Department 保安部Security Department 康乐部Recreation and Entertainment Department 行政部Rear-Service Department 工程部Engineering Department 商场部Shopping Arcade 董事总经理Managing Director 总经理秘书Executive Secretary 总经理General Manager 总经理室Executive Office 副总经理Deputy General Manager 机要秘书Secretary 驻店经理Resident Manager 接待文员Clerk 总经理行政助理Executive Assistant Manager 人力资源开发总监Director of Human Resource 督导部经理Quality Inspector 人事部经理Personnel Manager 人事主任Personnel Officer
经典的前厅部中英文资料 前台术语解释 Skipper 意思是故意逃账者； 其特征是：无行李或少行李者，使用假信用卡或假支票等； 对于无行李或少行李者都要留意其消费情况，使用假信用卡或假支票者，要收取其消费保证金。 Register 意思是入住登记，指要入住酒店的客人需要办理手续，如填写登记表等； 登记的意义在于可以确保客人身份的真实性，便于查询、联络和沟通； 登记的内容包括客人的姓名、出生年月、国籍、证件号码、签发机关、有效期等。 Upgrade 意思是将高价格种类的房间按低价格的出售； 用途：A、用于房间紧张时，给有预订的客人；B、提高接待规格给重要客人。 Early arrival 意思是提前到达。指客人在预订时间之前到达。 提前到达有两种情况：A、是指在预订日期之前到达。B、在酒店规定的入住时间之前到达。 无论以上哪种情况，都要妥善安排好客人。 Connecting room 意思是相连房。指相邻且相通的房间； 适于安排关系密切及需互相照顾的客人； 不宜安排敌对或不同种类的客人。 Room change 指为客人转换房间； 客人转房的两种主要原因是客人休息受到影响及房间设备出现问题； 转房的手续是：叫行李生拿新的房间钥匙及欢迎卡到客人的房间换旧的房匙及欢迎卡，请客人在新的欢迎卡上签名。最后通知相关部门，更改有关资料。 House use 指酒店人员用房； 酒店提供一部分房间给管理人员休息用，以便于工作； 要控制好酒店人员用房的数量 Guest history 意思是客史档案； 客人离店后，前台人员将客人的有关资料记录下来并加以保存； 客史档案是酒店极富价值的资料，有利于对客提供针对性、个性化的服务以及开展市场调研，以巩固和稳定客源市场。 Sleep out 是“馆外住宿”，简称“外宿”。 Tips
酒店前台常用礼貌服务 用语 Company Document number：WUUT-WUUY-WBBGB-BWYTT-1982GT
酒店前台常用礼貌 1、迎客时说“欢迎”、“欢迎您的光临”、“您好”等。 2、对他人表示感谢时说“谢谢”、“谢谢您”、“谢谢您的帮助”等。 3、接受宾客的吩咐时说“听明白了”、“清楚了，请您放心”等，严禁说“我知道了”。 4、不能立即接待宾客时说“请您稍候”、“麻烦您等一下”、“我马上就来”等。 5、对在等待的宾客说“让您久等了”、“对不起，让你们等候多时了”等。 6、打扰或给宾客带来麻烦时说“对不起”、“实在对不起”、“打扰您了”、“给您添麻烦了”等。 7、由于失误表示歉意时说“很抱歉”、“实在很抱歉”等。 8、当宾客向你致谢时说“请别客气”、“不用客气”、“很高兴为您服务”、“这是我应该做的”等。 9、当宾客向你致歉时说“没有什么”、“没关系”等。 10、当听不清楚宾客问话时说“很对不起，我没听清楚，请重复一遍好吗”等。
11、送客时说“再见”、“一路平安”、“再见，欢迎您下次再来”等。 12、当你要打断宾客时说“对不起，我可以占用一下您的时间吗”“对不起，打扰一下”等；在服务接待工作中，使用礼貌用语应做到主动、自然和熟练。要把“请”、“您好”、“谢谢”、“对不起”等最基本的礼貌用语与其他服务用语密切结合加以运用，给我们的服务工作增添绚丽的色彩。 酒店前台职业 ①站姿 古人云：站如松。男士则主要体现出阳刚之美，抬头挺胸，双脚大约与肩膀同宽站立，重心自然落于脚中间，肩膀放松。女士则体现出柔和和轻盈，丁字步站立。 谈话时，要面对对方，保持一定的距离。尽量保持身体的挺直，不可歪斜。依靠着墙壁、桌椅而站；双腿分开的距离过大、交叉，都是不雅观和失礼的行为。手中也不要玩弄物品，那样显的心不在焉，是不礼貌的行为。 ②行走
工作行为规范系列 酒店前台疑难问题处理术 语解释 （标准、完整、实用、可修改）
编号：FS-QG-16664酒店前台疑难问题处理术语解释Terminology explanation for difficult problems in hotel front desk 说明：为规范化、制度化和统一化作业行为，使人员管理工作有章可循，提高工作效率和责任感、归属感，特此编写。 酒店前台术语解释及其疑难问题处理 第一组 (一)前台术语解释: *Skipper 答:1.故意逃帐者。 2.特征:无行李或少行李者，使用假信用卡和假支票者等。 3.预防逃帐的措施。 *Commercialrate 答:1.商务房价。指酒店为争取更多的商务客人而与一些公司签订合同，给予他们优惠的房间价格。 2.商务房价比较固定，便于公务客人报销。 3.为享受商务房价的客人提供良好的服务。
4.做好统计工作，检查商务房间的销售效果。 (二)疑难问题处理: *客人要求在房间内摆放鲜花、水果时怎么办 答:1.了解客人所需鲜花、水果的种类、色彩、数量和摆放方式，并记下房号和姓名。 2.按要求进行摆设，要注意技巧，避免客人禁忌的花，水果要消毒。 3.尽量了解客人摆鲜花水果的原因，进一步做好细致的服务，如是客人生日 *某日，酒店机场代表按客人订房时所报的航班，持着写着该客人姓名的欢迎牌到机场出口处接此客人。但一直等到出口处没人出来了，仍不见客人出现，对此你应如何处理答:1.查清客人是否因某些原因在机场内受阻。 2.联系前台接待处看客人是否已回酒店。 3.请订房部职员根据客人订房时留下的通讯号码与客人联系，确认客人是否改变了行程。 4.如有条件可直接请民航有关部门查一下此客是否乘该航班到达。
HOTEL TERMINOLOGY & ABBREVIATION 酒店术语与缩写 A.DEPARTMENT: 部门 1、General Manager: GM 总经理 2、Deputy Manager 副总经理 3、Executive Office 总经理办公室 4、Personnel Department 人事部 5、Sales Department 销售部 6、Public Relation Department: PR 公关部 7、Front Office Department: FO 前厅部 8、Housekeeping Department: HSKP 管家部 9、Laundry Department 洗衣部 10、Food and Beverage Department: F& B 餐饮部 11、Account Department/Financial Department 财务部 12、Purchasing Department 采购部 13、Training Department 培训部 14、Engineering Department 工程部 15、Security Department 保安部 16、Computer room 电脑房 17、Public area : PA 公共区域 18、Duty manager 值班经理B. ADDRESS: 称呼 1、General Manager: GM 总经理 2、Department Head: DH 部门经理 3、Directory of sales: DOS 销售总监 4、Front Office Manager: FOM 前厅经理 5、Assistant FOM: AFOM 前厅副经理 6、Assistant Manager: AM 大堂副理 7、Supervisor 主管 8、Assistant Supervisor 副主管 9、Captain/Shift Leader 领班 10、Financial controller: 财务总监 C: Front Office Section 前厅各分部 1、Reception: Recp (Receptionist) 接待处 2、Reservation: Rsvn 订房部 3、Concierge/Bell counter 礼宾部 4、Operator 总机 5、Business Center: BC 商务中心 6、Front office cashier: FOC 前厅收银 7、Transportation 租车服务 8、Mail & Information 邮件及问询
Guidelines for Project Proposals* A technical proposal, often called a "Statement of Work,” is a persuasive document. Its objectives are to 1. Identify what work is to be done 2. Explain why this work needs to be done 3. Persuade the reader that the proposers (you) are qualified for the work, have a plausible management plan and technical approach, and have the resources needed to complete the task within the stated time and cost constraints. What makes a good proposal?One attribute is appearance. A strong proposal has an attractive, professional, inviting appearance. In addition, the information should easy to access. A second attribute is substance. A strong proposal has a well-organized plan of attack. A strong proposal also has technical details because technical depth is needed to sell your project. Remember: A proposal is a persuasive document. Required Format Format consists of the layout and typography of a document. In formatting your proposal, use the guidelines in Table 1. A template to produce your proposal exists at the following web page: https://www.doczj.com/doc/9817679585.html,/design/proposal_template.doc One aspect of layout is the incorporation of illustrations. In your proposal, each illustration should have a name and be formally introduced in the text. Illustrations consist of figures and tables. Figures include photographs, drawings, diagrams, and graphs. Each figure should have a stand-alone caption, and the key points and features should be labeled. Tables are arrangement of words and numbers into rows and columns. Use tables to summarize lists that the audience will try to find later (the budget, for instance). Table 1.Format guidelines for requested proposal. Aspect Description Font for headings Boldface serif or sans serif: size in accordance with hierarchy Font for text portion 12-point serif such as Times New Roman or Book Antiqua Margins Standard, at least 1 inch Layout One column, single-sided Paragraphing Indented paragraphs, no line skip between paragraphs in a section Page number Bottom centered Figure names Numbered: Figure 1, Figure 2, Figure 3, and so forth Figure captions Below figure in 10 point type Table names Numbered: Table 1, Table 2, Table 3, and so forth Table headings Above table in 12 point type * Adapted from Guidelines at the Penn State Learning Factory: https://www.doczj.com/doc/9817679585.html,/
总贝y 俗话说：“良言一句三冬暖，恶语伤人六月寒。”中国曾有“君子不失色于人，不失口于人”的古训。作为酒店服务从业人员，规范的礼貌用语不光是个人素质的体现，更是酒店形象的彰显。 一、用语基本要求 1、说话要尊称，态度平稳； 2、说话要文雅，简练，明确； 3、说话要婉转热情； 4、说话要讲究语言艺术，力求语言优美，婉转悦耳； 5、与宾客讲话要注意举止表情。 二、礼貌基本要求 1、“三轻四勤” 走路轻，说话轻，操作轻； 嘴勤，眼勤，腿勤，手勤。 2、“五声六语十一字” 客来有迎声，客问有答声，工作失误道歉声，受到帮助致谢声，客人走时送客声； 问候用语，征求用语，致歉用语，致谢用语，尊称用语，道别用语； 请，您，您好，谢谢，对不起，再见。
3、“四不四忌三不较” 不讲粗话，不讲脏话，不讲讽刺话，不讲与服务无关的话； 忌蔑视语，忌否定语，忌顶撞语，忌烦躁语； 不计较宾客不美的语言，不计较宾客急躁的态度，不计较宾客无理的要求 第一章通用规范服务礼貌用语 一、问候用语............................................... ( 4) 二、征询用语............................................... ( 4) 三、尊称用语 (4) 四、致歉用语 (4) 五、致谢用语 (4) 六、应答用语............................................... ( 4) 七、欢迎用语............................................... ( 4)
? Copyright ? 2006 World Customs Organization. All rights reserved. Requests and inquiries concerning translation, reproduction and adaptation rights should be addressed to copyright@https://www.doczj.com/doc/9817679585.html, ?. AUTHORIZED ECONOMIC OPERATOR I. CONDITIONS, REQUIREMENTS AND BENEFITS Introduction The World Customs Organization (WCO) has designed standards to secure and to facilitate the ever-growing flow of goods in international commerce. These standards are set forth in the SAFE Framework of Standards (“SAFE Framework ”), which was adopted by the WCO Council at its 2005 Sessions. A vast majority of WCO Member administrations have expressed the intention to begin the process of implementing the SAFE Framework provisions. In recognition of the urgency of launching this new programme without undue delay, the Council adopted the basic SAFE Framework document which provides the broad overarching principles concerning security and facilitation of the global supply chain. The SAFE Framework incorporates the concept of the Authorized Economic Operator (AEO), and the Council directed the WCO to develop more detailed implementing provisions for the AEO concept. This document provides baseline technical guidance for the implementation of AEO programmes at the global level between WCO Members and the international trade community. It is designed to serve as a starting point for national AEO programme implementation and supports the effective application of the standards that are outlined in Pillar II (Customs-to-Business Partnerships) of the SAFE Framework. This guidance will provide for long-term application of meaningful standards that will apply to both Customs and AEOs at the global level. These core international standards shall form a “baseline ” that must be followed by all parties engaged in this effort. This document also allows for the inclusion of supplemental national criteria that may be required by any given Customs administration. Customs administrations recognize that the international trade supply chain is not a discrete identifiable entity. Rather, it is a series of ad hoc constructs comprised of players representing varied trade industry segments. Some “supply chains ” possess a degree of permanence in that the same cast may play recurring roles on a long-term basis on behalf of a regular importer of goods into a given country. In other “supply chains ”, participants either change frequently or are assembled for the purpose of executing a single import transaction. Regardless of either the regularity or the temporal nature of any particular supply chain, Customs does appreciate that it does not own any portion of the trade supply chain. The global supply chain is “owned ” by the multitudes in the private sector who operate as part of any chain. It is for this reason that the support and participation of private sector business interests is fundamental to the success of the SAFE Framework concept.
前厅常用术语介绍第一部份 1.前厅岗位专业术语介绍 房务部:Rooms Division 前厅部:Front Office 客房部:Housekeeping 大堂副理:Assistant Manager 宾客关系主任:Guest Relation Officer 前台:Front Desk 接待处:Reception/Check-in 收银处:Cashier/Check-out 领班:Captain 主管:Supervisor 班次负责人:Shift Leader 商务中心:Business Center 电话总机:Switch Board 接线员:Operator 预订处:Room Reservation 礼宾服务处:Concierge 大厅服务处:Bell Service 金钥匙:Golden Key 行政楼层:Executive Floor
行政酒廊:Executive Lounge 行李生:Bellman 迎宾员:Doorman 夜审:End of Day /Night auditor 客房服务代表:Guest service agent(接待和收银合并之后的前台人员的称呼简称GSA 2.前厅服务项目专业术语介绍 入住:Check-in 退房:Check-out 外币兑换:Foreign Currency Exchange 问询:Information 接送机服务:Pick up service 叫醒服务:Wake up call 请勿打扰服务:DND Do not disturbed 失物招领:Lost and Found 国内直拨和国际直拨电话:DDD and IDD (Domestic Direct Dial and International Direct Dial 对方付费电话:Collect Call 3.前厅常用物品术语介绍 住宿登记单:Registration card 欢迎卡:Welcome card 订房凭证:Voucher
第一部分前厅常用术语介绍 1.前厅岗位专业术语介绍 房务部：Rooms Division 前厅部：Front Office 客房部： Housekeeping 大堂副理：Assistant Manager 宾客关系主任：Guest Relation Officer 前台：Front Desk 接待处：Reception/Check-in 收银处：Cashier/Check-out 领班： Captain 主管：Supervisor 班次负责人：Shift Leader 商务中心：Business Center 客房服务代表：Guest service agent(接待和收银合并之后的前台人员的称呼)简称GSA 电话总机：Switch Board 接线员：Operator 预订处：Room Reservation 礼宾服务处：Concierge 大厅服务处：Bell Service 金钥匙：Golden Key 行政楼层：Executive Floor 行政酒廊：Executive Lounge 行李生：Bellman 迎宾员：Doorman 夜审：End of Day /Night auditor 2．前厅服务项目专业术语介绍 入住：Check-in 退房：Check-out 外币兑换：Foreign Currency Exchange 问询：Information 接送机服务：Pick up service 叫醒服务：Wake up call 请勿打扰服务：DND Do not disturbed 失物招领：Lost and Found 国内直拨和国际直拨电话：DDD and IDD (Domestic Direct Dial and International Direct Dial) 对方付费电话：Collect Call 3．前厅常用物品术语介绍： 住宿登记单：Registration card 欢迎卡：Welcome card 订房凭证：Voucher 交接本：log book 信封： Envelope 房卡钥匙：Room key 安全保管箱：Safe Deposit Box 第二部分： 1．客房统计和出售率统计的术语 预离房：Expected Departure 预抵房：Expected Arrival 实际抵店： Actual Arrival 实际离店：Actual Departure 续住：Extension 白天用房：Day use 提前离店：Early Departure 提前入住：Early Check-in 门市客：Walk in 预定未到：No Show 预定取消：Cancellation 在店客人：Stay over 住店客人：In House 营业日报（daily operations report）： 一份报告，一般由夜审制作，它总结24小 时内饭店的财务活动，洞察与前厅部相关的 收入、应收款、营业统计，以及现金交易。 它又被称为经理的报告。 预测（forecasting）：预告活动和业务趋 势的过程；房务部门制作的预测通常有可销 售房预测和出租率预测； 出租率：Occupancy Ratios：一种衡量饭 店客房销售业绩的尺度；标准的住房比例包 括日平均房价，每间可销售房收入，每位客 人平均价格，多人居住统计数和出租房百份 比； 每日平均房价（average daily rate， average room rate）：用客房净收入除 以售出房数量产生的一种出租比例； 每位客人平均房价（average rate per guest）：用客房净收入除以客人人数产生 的一个出租比例；