As per Relevance of the word identification, we have this rfc below:
Network Working Group D.
Request for Comments: 3140 S.
Obsoletes: 2836 B.
Category: Standards Track F. Le
June 2001
Per Hop Behavior Identification
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document defines a 16 bit encoding mechanism for
identification of differentiated services Per Hop Behaviors
protocol messages. It replaces RFC 2836.
Table of
1. Introduction.................................................2
1.1. Usage Scenarios............................................2
2. Encoding.....................................................3
3. Signalling the Class Selector Codepoints.....................4
4. IANA Considerations..........................................5
5. Security Considerations......................................5
Changes from RFC 2836...........................................5
Acknowledgements................................................6
References......................................................6
Authors' Addresses..............................................6
Intellectual Property...........................................7
Full Copyright Statement........................................8
Black, et al. Standards Track [Page 1]
RFC 3140 Per Hop Behavior Identification Codes June 2001
1.
Differentiated Services [RFC 2474, RFC 2475] introduces the notion
Per Hop Behaviors (PHBs) that define how traffic belonging to
particular behavior aggregate is treated at an individual
node. In IP packet headers, PHBs are not indicated as such;
Differentiated Services Codepoint (DSCP) values are used. There
only 64 possible DSCP values, but there is no such limit on
number of PHBs. In a given network domain, there is a
defined mapping between DSCP values and PHBs. Standardized
recommend a DSCP mapping, but network operators may
alternative mappings
In some cases it is necessary or desirable to identify a
PHB in a protocol message, such as a message negotiating
management or path selection, especially when such messages
between management domains. Examples where work is in
include communication between bandwidth brokers, and MPLS support
diffserv
In certain cases, what needs to be identified is not an
PHB, but a set of PHBs. One example is a set of PHBs that
follow the same physical path to prevent re-ordering. An instance
this is the set of three PHBs belonging to a single
Forwarding class, such as the PHBs AF11, AF12 and AF13 [RFC 2597].
This document defines a binary encoding to uniquely identify
and/or sets of PHBs in protocol messages. This encoding MUST be
when such identification is required
This document replaces RFC 2836, which omitted considerations for
Class Selector codepoints
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC2119].
1.1. Usage
Diffserv services are expected to be supported over
underlying technologies which we broadly refer to as "link layers
for the purpose of this discussion. For the transport of IP packets
some of these link layers make use of connections or
connections where the forwarding behavior supported by each
layer device is a property of the connection. In particular,
the link layer domain, each link layer node will schedule
depending on which connection the traffic is transported in
Examples of such "link layers" include ATM and MPLS
Black, et al. Standards Track [Page 2]
RFC 3140 Per Hop Behavior Identification Codes June 2001
For efficient support of diffserv over these link layers, one
is for different Behavior Aggregates (BAs) (or sets of
Aggregates) to be transported over different connections so that
are granted different (and appropriate) forwarding behaviors
the link layer cloud. When those connections are
established for the transport of diffserv traffic, it is very
to communicate at connection establishment time what
behavior(s) is (are) to be granted to each connection by the
layer device so that the BAs transported experience
forwarding behavior inside the link layer cloud. This can
achieved by including in the connection establishment
messages the encoding of the corresponding PHB, or set of PHBs,
defined in this document. Details on proposed usage of PHB
by some MPLS label distribution protocols (RSVP and LDP) for
of Diff-Serv over MPLS, can be found in [MPLS-DS].
In another approach, the ATM Forum has a requirement to
desired IP QOS treatments in ATM signaling, so that ATM switches
be just as supportive of the desired service as are IP forwarders
To do so the Forum is defining a new VC call setup
element is which will carry PHB identification codes (although
be generalized to do more if needed).
2.
PHBs and sets of PHBs are encoded in an unsigned 16 bit binary field
The 16 bit field is arranged as follows
Case 1: PHBs defined by standards action, as per [RFC 2474].
The encoding for a single PHB is the recommended DSCP value for
PHB, left-justified in the 16 bit field, with bits 6 through 15
to zero. Note that the recommended DSCP value MUST be used, even
the network in question has chosen a different mapping
The encoding for a set of PHBs is the numerically smallest of the
of encodings for the various PHBs in the set, with bit 14 set to 1.
(Thus for the AF1x PHBs, the encoding is that of the AF11 PHB,
bit 14 set to 1.)
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| DSCP | 0 0 0 0 0 0 0 0 X 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Black, et al. Standards Track [Page 3]
RFC 3140 Per Hop Behavior Identification Codes June 2001
Case 2: PHBs not defined by standards action, i.e., experimental
local use PHBs as allowed by [RFC 2474]. In this case an
12 bit PHB identification code, assigned by the IANA, is
left-justified in the 16 bit field. Bit 15 is set to 1, and bit 14
is zero for a single PHB or 1 for a set of PHBs. Bits 12 and 13
zero
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| PHB id code | 0 0 X 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Bits 12 and 13 are reserved either for expansion of the
identification code, or for other use, at some point in the future
In both cases, when a single PHBID is used to identify a set of
(i.e., bit 14 is set to 1), that set of PHBs MUST constitute a
Scheduling Class (i.e., use of PHBs from the set MUST NOT
intra-microflow traffic reordering when different PHBs from the
are applied to traffic in the same microflow). The set of AF1x
[RFC 2597] is an example of a PHB Scheduling Class. Sets of
that do not constitute a PHB Scheduling Class can be identified
using more than one PHBID
3. Signalling the Class Selector
[RFC 2474] defines the eight DS codepoint values of the form 'xxx000'
(where x may be '0' or '1') as the Class Selector Codepoints
Codepoint 000000 is the recommended DSCP value for the Default PHB
and hence the Case 1 PHBID constructed from that codepoint is used
signal the Default PHB (see Section 2 above).
For convenience and consistent operation with networks that employ
Precedence [RFC 1812], the Case 1 format PHBIDs constructed from
other seven Class Selector Codepoints may also be used to
PHBs. In each case, the PHB signaled by such a PHBID is the PHB
which the embedded class selector codepoint (or IP Precedence
that corresponds to it in non-diffserv domains) is mapped in
recipient's network. Note that different networks will
different mappings; see Section 4 of [RFC 2474] for
discussion
Any specified use of PHBIDs SHOULD allow the use of the eight Case 1
PHBIDs constructed from the Class Selector Codepoints
Black, et al. Standards Track [Page 4]
RFC 3140 Per Hop Behavior Identification Codes June 2001
4. IANA
IANA is requested to create a new assignment registry for "Per-
Behavior Identification Codes", initially allowing values in
range 0 to 4095 decimal
Assignment of values in this field require
- the identity of the
- a brief description of the new PHB, with enough detail
distinguish it from existing standardized and non-
PHBs. In the case of a set of PHBs, this description
cover all PHBs in the set
- a reference to a stable document describing the PHB in detail
During the first year of existence of this registry, IANA
requested to refer all requests to the IETF diffserv WG for review
Subsequently, requests should be reviewed by the IETF Transport
Directors or by an expert that they designate
If the number of assignments begins to approach 4096, the
Area Directors should be alerted
5. Security
This encoding in itself raises no security issues. However, users
this encoding should consider that modifying a PHB
code may constitute theft or denial of service, so protocols
this encoding must be adequately protected
Just signalling a PHBID SHOULD NOT be sufficient to grant the
access to a PHB that it would otherwise not be able to use. In
where this is an issue, receivers SHOULD treat received PHBIDs
requests for service, and use local policy to determine whether
grant or deny such requests
Changes from RFC 2836
[RFC 2836] did not consider the Class Selector code points, which
covered by section 3 of the present document. A clarification
been added at the end of section 2 for the case of PHB
Classes. The second paragraph of section 5 has been added
Black, et al. Standards Track [Page 5]
RFC 3140 Per Hop Behavior Identification Codes June 2001
Useful comments were made by members of the IETF Diffserv
group
[RFC 2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2474] Nichols, K., Blake, S., Baker, F. and D. Black
"Definition of the Differentiated Services Field (
Field) in the IPv4 and IPv6 Headers", RFC 2474,
1998.
[RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z
and W. Weiss, "An Architecture for
Services", RFC 2475, December 1998.
[RFC 2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC 2836] Brim, S., Carpenter, B. and F. Le Faucheur, "Per
Behavior Identification Codes", RFC 2836, May 2000.
[MPLS-DS] Le Faucheur, F., et al., "MPLS Support of
Services", Work in Progress
Authors'
David L.
EMC
42 South St
Hopkinton, MA 01748
EMail: black_david@emc.
Scott W.
146 Honness
Ithaca, NY 14850
EMail: sbrim@cisco.
Black, et al. Standards Track [Page 6]
RFC 3140 Per Hop Behavior Identification Codes June 2001
Brian E.
c/o
Suite 150
1890 Maple
Evanston, IL 60201
EMail: brian@icair.
Francois Le
Cisco
Petra B - Les
291, rue Albert
06560
EMail: flefauch@cisco.
Intellectual
The IETF takes no position regarding the validity or scope of
intellectual property or other rights that might be claimed
pertain to the implementation or use of the technology described
this document or the extent to which any license under such
might or might not be available; neither does it represent that
has made any effort to identify any such rights. Information on
IETF's procedures with respect to rights in standards-track
standards-related documentation can be found in BCP-11. Copies
claims of rights made available for publication and any assurances
licenses to be made available, or the result of an attempt made
obtain a general license or permission for the use of
proprietary rights by implementors or users of this specification
be obtained from the IETF Secretariat
The IETF invites any interested party to bring to its attention
copyrights, patents or patent applications, or other
rights which may cover technology that may be required to
this standard. Please address the information to the IETF
Director
Black, et al. Standards Track [Page 7]
RFC 3140 Per Hop Behavior Identification Codes June 2001
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Black, et al. Standards Track [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
