One document matched: draft-polk-tsvwg-signaled-domain-id-00.txt
TSVWG James Polk
Internet-Draft Subha Dhesikan
Intended status: Standards Track (PS) Cisco Systems
Expires: Jan 2nd, 2008 July 2nd, 2007
Updates: RFC 3181
Signaled Domain and Sub-domain Identification Element
draft-polk-tsvwg-signaled-domain-id-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on Jan 2nd, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document defines a domain and a sub-domain identification
element for use by signaled policy based admission protocols such as
Resource ReSerVation Protocol (RSVP) and Common Open Policy Service
(COPS). This element identifies the domain and sub-domain to which
the reservation belongs and is used, along with the PREEMPTION_PRI
element, to make capacity-based admission control (CAC) decisions.
Polk & Dhesikan Expires Jan 2008 [Page 1]
Internet-Draft Signaled Domain and Sub-Domain Element July 2007
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Functional Summary . . . . . . . . . . . . . . . . . . . . . 4
4. DOMAIN_SUBDOMAIN Element . . . . . . . . . . . . . . . . . . 5
5. Rules of use of the DOMAIN_SUBDOMAIN Element . . . . . . . . 6
6. DOMAIN_SUBDOMAIN Element Errors . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informational References . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . 9
1. Introduction
This document defines a domain/sub-domain identification element for
use by signaled policy based admission protocols such as RSVP
[RFC2205] and COPS [RFC2748]. This element identifies the domain
and sub-domain to which the reservation belongs and is used along
with the PREEMPTION_PRI element [RFC3181] to make capacity-based
admission control (CAC) decisions. This is independent of whether
the reservation is individual, a tunnel or an aggregate.
RFC 3181 allows a reservation from one domain to preempt a
reservation from another domain. This may not be a desirable action
as priorities are relative within a domain and the preempted
reservation may be just as important as the reservation that has
been newly admitted. There is also a risk of some domains
arbitrarily using high priority values to gain a better chance at
network resources than reservations from other domains. Hence, the
need for the domain and sub-domain identification information within
a reservation request to limit reservations considered for
preemption to be within the same domain/sub-domain.
To meet this requirement, two identifiers are necessary, one is a
unique domain identifier, and the other is a sub-domain identifier.
RFC 3181 [RFC3181] provides a reservation preemption priority policy
element (PREEMPTION_PRI), which defines the relative priority one
reservation has when compared to another when deciding to admit a
flow, and another relative priority value for defending against
Polk & Dhesikan Expires Jan 2008 [Page 2]
Internet-Draft Signaled Domain and Sub-Domain Element July 2007
preemption from a future flow.
Attempting to replace RFC 3181 with a rewritten document that carves
out a domain value and a subdomain value within the existing 16 bit
preemption priority field, while maintaining the existing admitting
priority value appears to be less than optimal, given the number of
domains that can be registered as unique. The same limitation holds
for the 16 bit defending priority field.
Therefore, a new element needs to be created to satisfy the
domain/sub-domain identifier requirements stated above - and
preserve the preemption priority policy element defined within RFC
3181.
This element creates the ability to preserve the original
domain/subdomain-values, while allowing transit network domains to
have their own identifiers while the their portion of the network,
relative to the end-to-end flow.
This document updates RFC 3181.
2. Motivation
The requirement of differing sub-domain treatments of flows allows a
single domain to administer how a group of endpoints can communicate
relative to the rest of the endpoints within the network. To give a
concrete example, lets look at a country's military organizations
communicating with each other, within their own branches of the
service. A policy can be established within this government
communications such that each branch of the military has the per
flow ability to preempt higher priority flows only within the same
branch of service, and not preempt flows existing at a saturated
network interface identified as from any other branch of the
military. This is regardless of the priority value indicated in the
flow establishment or flow retention.
To accomplish this scenario, three pieces of information are
required: the priority of the flow, the sub-domain of the branch of
service the user of the flow is in, and the overall domain of this
government's network. RSVP affords the additional ability to
distinguish the difference between the call establishment and call
retention to allow a flow to be established at a higher priority
than that same flow is defending against being preempted by future
flows.
Once a router interface becomes saturated, and cannot allow any
additional calls through that interface, the router has to make
preemption decisions if it decides to allow future flows, provided
none of the existing flows terminate somewhere else. As described
in [ID-RPH-DISA] for how the Session Initiation Protocol (SIP)
Polk & Dhesikan Expires Jan 2008 [Page 3]
Internet-Draft Signaled Domain and Sub-Domain Element July 2007
addresses this issue, this DOMAIN_SUBDOMAIN element will provide the
final two pieces of information necessary to meet the desired
functionality.
3. Functional Summary
This DOMAIN-SUBDOMAIN element is an encapsulation of the Policy Data
object which is defined in [RFC2750]. This element may be present
in RSVP PATH and RESV message. If the element is present in the PATH
message, it is used in policy control. In the RESV message, the
element is used for not only policy control but also for resource
control.
If the DOMAIN_SUBDOMAIN element is present in any RSVP message, the
PREEMPTION_PRI element needs to be present as well. The reverse is
not true.
The DOMAIN-SUBDOMAIN element may be created along with the
PREEMPTION-PRI element at the RSVP host where the PATH or RESV
message originates. It is then carried to the RSVP-enabled routers
along the path in the RSVP message. Alternatively, the element may
be inserted by the intermediate RSVP routers. This is done when this
element, along with the PREEMPTION-PRI element, is created by the
Policy Decision Points (PDP) or the Local decisions Points (LDP)
along the path. The PDP/LDP creates this element and provides it to
the PEP for insertion into the RSVP message before the message is
forwarded.
PDP, LDP and/or PEP use the contents of this element to make
decisions on the treatment of the PATH and RESV message. When a
RSVP-enabled router receives the PREEMPTION-PRI element and the
DOMAIN_SUBDOMAIN element, it may hand these elements to the LDP/PDP
if configured to do so. The PDP/LDP uses these elements in making
policy control decisions. The decision is then conveyed to the PEP
for enforcement. The RSVP messages containing these elements are
then forwarded to the next hop. The PDP/LDP may ask for the elements
to be removed before forwarding as well.
If an error occurs during the processing of the DOMAIN-SUBDOMAIN
element, the PathErr or ResvErr is returned as appropriate. The
error information is then added to the PREEMPTION_PRI object and
included in the error message as stated in RFC 3181.
When a RSVP message containing this element enters a different
domain during transit, the PDP/LDP in the new domain may add a
Transit-Domain-value and a Transit-Sub-Domain-value for use within
the transit domain. This is done as the original domain and
sub-domain id may not be relevant within the new domain. In such a
case, the edge LDP/PDP may translate the original domain and
sub-domain id to a transit domain and sub-domain id based on SLAs or
other criteria and add it to the RSVP message. The original ids are
Polk & Dhesikan Expires Jan 2008 [Page 4]
Internet-Draft Signaled Domain and Sub-Domain Element July 2007
left unchanged. The transit ids are removed when exiting the transit
domain.
4. DOMAIN_SUBDOMAIN Element
The format of DOMAIN_SUBDOMAIN identification element is as follows:
+-------------+-------------+-------------+-------------+
| Length (16) | P-Type = DOMAIN_SUBDOMAIN |
+------+------+-------------+-------------+-------------+
| TBD | Reserved(0) |
+-------------+-------------+-------------+-------------+
| Transit Domain-Value | Original Domain-Value |
+-------------+-------------+-------------+-------------+
| Transit Sub-Domain-Value | Original Sub-Domain-Value |
+-------------+-------------+-------------+-------------+
Length: 16 bits
Always 16. The overall length of the policy element, in bytes.
P-Type: 16 bits
DOMAIN_SUBDOMAIN = XXXX (to be assigned by IANA)
TBD field: (currently) 16 bits
(this may be one or two fields)
(to be fleshed out in next rev of doc)
Reserved: 16 bits
Always 0. (for future extensibility)
Transit domain-value: 16 bits (IANA assigned)
An IANA registered domain identifier of the network the packet is
in now
Original domain-value: 16 bits (IANA assigned)
An IANA registered domain identifier of the original network
which started this flow.
If the DOMAIN_SUBDOMAIN element is in a packet within the
original domain (or on either end of a domain1->domain2->domain1
scenario), these two domain-values are the same.
Transit sub-domain-value: 16 bits (unassigned)
Transit domain's sub-domain identifier
Original sub-domain-value: 16 bits (unassigned)
Locally controlled sub-domain identifier of a subgroup of nodes
within the original domain
If the DOMAIN_SUBDOMAIN element is in a packet within the
original domain (or on either end of a domain1->domain2->domain1
Polk & Dhesikan Expires Jan 2008 [Page 5]
Internet-Draft Signaled Domain and Sub-Domain Element July 2007
scenario), these two sub-domain-values are the same.
[Editor's note: we might build a table to show the above point]
The domain and subdomain values MAY be paired with SIP
Resource-Priority header (RPH) namespace [RFC4412] with the
delimiter defined in [ID-RPH-DISA] as how an RPH namespace is
divided into two parts.
Editor's note: Should merging be considered within this document
(along the lines of how it is in RFC 3181)?
5. Rules of use of the DOMAIN_SUBDOMAIN Element
The following rules are to be followed when utilizing the
DOMAIN_SUBDOMAIN element:
- the DOMAIN_SUBDOMAIN element is optional (i.e., RSVP/COPS will
function if this element is not in a message)
- If a Domain-value is required within a network, there MAY or MAY
NOT be a Sub-domain-value within that network (i.e., this element
can be used merely to identify a domain in which there are no
sub-domains).
- Domain-values are IANA registered to be unique per network (i.e.,
Cisco would have one domain identifier throughout the company's
network).
- There is no difference between a Transit and Original domain from
IANA's point of view. IANA controls the one registration list.
- Sub-Domain-values are not to be registered, and are to be
administered locally, if present in the element.
- Domain-values not understood SHOULD be ignored, thereby treating
the reservation request as if this element weren't present in the
PATH or RESV message (in the case of RSVP).
- Sub-Domain-values not understood should be considered as if there
was no sub-domain-value in the element (i.e., a default of 0,
which MUST be valid in any network having sub-domains).
- Network or domain border entities SHOULD NOT change Domain-value
field when exiting or entering a network boundary. This can cause
problems when sending packets in the reverse direction. An
exception to this rule is in such cases the value(s) can be
successfully changed back in the reverse direction.
- The Transit-Domain-value is to be changed when existing a domain.
The burden of entering a new value is on the ingress node of the
Polk & Dhesikan Expires Jan 2008 [Page 6]
Internet-Draft Signaled Domain and Sub-Domain Element July 2007
new domain in during the e2e flow.
- The Original-Domain-value MUST NOT be changed at reservation
establishment or while the reservation remains operational.
- The Original-Sub-Domain-value MUST NOT be changed at reservation
establishment or while the reservation remains operational.
- This DOMAIN_SUBDOMAIN element MUST be accompanied by the
PREEMPTION_PRI element defined in [RFC3181].
- Since the DOMAIN_SUBDOMAIN element MUST be accompanied by the
PREEMPTION_PRI element, implementers ought have to look for an
error in only one place. Therefore, DOMAIN_SUBDOMAIN error codes
will be added to the PREEMPTION_PRI element error field, of which
there are presently only 3 IANA registered.
- The PREEMPTION_PRI element defined in [RFC3181] MAY be in a PATH
or RESV message (in RSVP) without this DOMAIN_SUBDOMAIN element
but the reverse is not true.
6. DOMAIN_SUBDOMAIN Element Errors
There is no error field in this element, but there are errors
associated with this element. This element's errors will be in the
PREEMPTION_PRI error field defined in [RFC3181], that currently only
has 3 errors IANA registered.
New DOMAIN_SUBDOMAIN errors are TBD at this time.
7. Security Considerations
The integrity of DOMAIN_SUBDOMAIN element is guaranteed, as any
other policy element is, by the encapsulation into a Policy Data
object [RFC2750].
As such, this document introduces no additional security
considerations above that found in [RFC3181].
8. IANA Considerations
The following is to be IANA assigned within the RSVP parameters
registration area. Extensions to this document requesting new IANA
registrations MUST be done through a standards track RFC to ensure
community review.
8.1 DOMAIN_SUBDOMAIN P-Type Registration
IANA shall register DOMAIN_SUBDOMAIN as a new P-Type, similar to how
Polk & Dhesikan Expires Jan 2008 [Page 7]
Internet-Draft Signaled Domain and Sub-Domain Element July 2007
PREEMPTION_PRI was registered from RFC 3181. Please refer to
section 4 of this document for the element's format.
8.2 Domain-value Registration
IANA shall register each network requesting a domain number be
assigned to it. Subdomain-values are not registered.
[an example of this registration table will be built in a future rev
of this doc].
9. Acknowledgements
None at this time.
10. References
10.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
[RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997
[RFC2748] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and
A. Sastry, "The COPS (Common Open Policy Service) Protocol",
RFC 2748, January 2000.
[RFC3181] S. Herzog, "Signaled Preemption Priority Policy Element",
RFC 3181, October 2001
[RFC2750] S. Herzog, "RSVP Extensions for Policy Control", RFC 2750,
January 2000
[RFC4412] Schulzrinne, H., Polk, J., "Communications Resource
Priority for the Session Initiation Protocol (SIP)", RFC
4411, Feb 2006
10.2. Informational References
[ID-RPH-DISA] J. Polk "New Session Initiation Protocol
Resource-Priority Header Namespaces for the Defense
Information Services Agency",
draft-polk-sip-rph-new-namespaces-00, "work in progress",
Feb 2007
Polk & Dhesikan Expires Jan 2008 [Page 8]
Internet-Draft Signaled Domain and Sub-Domain Element July 2007
Authors' Addresses
James Polk
Cisco Systems
3913 Treemont Circle
Colleyville, Texas
USA
Email: jmpolk@cisco.com
Subha Dhesikan
Cisco Systems
170 W Tasman St
San Jose
CA-95135
sdhesika@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Polk & Dhesikan Expires Jan 2008 [Page 9]
Internet-Draft Signaled Domain and Sub-Domain Element July 2007
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Polk & Dhesikan Expires Jan 2008 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-22 23:21:36 |