One document matched: draft-polk-mmusic-dscp-attribute-02.txt
Differences from draft-polk-mmusic-dscp-attribute-01.txt
MMUSIC Working Group James Polk
Internet-Draft Cisco Systems
Expires: Aug 23, 2008 February 23, 2008
Intended Status: Standards Track
Configuring the Differentiated Services Codepoint of
Session Description Protocol Established Media Streams
draft-polk-mmusic-dscp-attribute-02
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 Feb 23, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
The Session Description Protocol (SDP) offer/answer model currently
has no mechanism for dynamic configuration of the Differentiated
Services Codepoints (DSCP) for the media streams endpoints
establish. This document creates such a mechanism within SDP, as
granular as at the media stream level where more than one stream can
be in an offer/answer exchange, to set a particular DSCP for the
desired Per Hop Behavior (PHB) of a media stream. This same
mechanism can change a DSCP of an existing stream based on dynamic
network conditions.
Polk Expires Aug 2008 [Page 1]
Internet-Draft DSCP Stream Configuration in SDP Feb 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Changes Since Last Version . . . . . . . . . . . . . . . . 3
2. SDP Attributes Definition . . . . . . . . . . . . . . . . . . 4
3. Offer/Answer Behavior . . . . . . . . . . . . . . . . . . . . 5
3.1 Offerer Behavior . . . . . . . . . . . . . . . . . . . . . 6
3.2 Answerer Behavior . . . . . . . . . . . . . . . . . . . . . 7
4. Changing the 'dscp' Attribute in an Established Session . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5.1 Registration of the SDP 'dscp' Attribute . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1 Normative References . . . . . . . . . . . . . . . . . . 11
9.2 Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . 12
Copyright and Intellectual Property Statements . . . . . . . 12
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
levels for compliant implementations.
1. Introduction
The Session Description Protocol (SDP) [RFC4566] currently is
neutral with respect to offering or modifying any domain per hop
behavior (PHB) indications during session establishment or session
update. Leaving this task for another mechanism to set, even if it
is administratively fixed per application, such as 'voice always has
the same indication', or 'video always has this other indication'.
This fixed basis is undergoing a change, combining the IETF
guidelines in [RFC4594] and [RFC5127] with the motivations
surrounding [ID-VOICE-ADMIT], SDP becomes the logical place to solve
per session indications like this.
Differentiated Services [RFC2474] established a set of per hop
behavior indications at layer 3, creating Differentiated Services
Codepoints (DSCP) to be viewed by intermediate routers to provide
packet treatment based upon these indicators.
Additionally, there is no current capability in control plane
signaling (aside from SDP's current inability) for an endpoint to
offer, suggest, indicate or otherwise set a DSCP of a media stream;
much less modify a default fixed codepoint. Example control plane
signaling protocols here include SIP [RFC3261], MGCP [RFC3435] and
Polk Expires Aug 2008 [Page 2]
Internet-Draft DSCP Stream Configuration in SDP Feb 2008
MEGACO [RFC3015] - which all utilize SDP for session capabilities.
Further, none of these 3 signaling protocols have awareness that SDP
has one or more session descriptions within a single offer.
Therefore, it appears as if these signaling protocols are not suited
for satisfying the requirement of per stream DSCP control.
SDP has such an awareness because it can include more than one
stream description within a single offer [RFC3264], possibly with
each stream needing to use a different DSCP, for example, a voice
and a video stream. Thus, it seems appropriate to provide the means
of indicating which DSCP a stream is to have by the protocol that
has the visibility and knowledge of each stream. SDP's knowledge of
the desired characteristics of the packet flow provides for this.
This document specifies a solution to this lack of ability - in SDP.
There are times and environments in which the DSCP for a particular
voice session, for example, will need to be different than other
voice sessions, even from same endpoint. See [ID-VOICE-ADMIT],
which describes and creates a new Expedited Forwarding DSCP (45 or
101101) for network admitted mission critical communicates. There
are times in which, from the same endpoint, the DSCP of the same
application (i.e., voice) will need to be different based on the
conditions of the network, or the type of communication attempted.
An example of usage is to provide this session with unique and/or
elevated treatment, with an indication how these packets are placed
into which MPLS tunnel. This elevated treatment can be achieved on
a per stream basis, or for each stream with this indication if a
router is configured to schedule/police this traffic differently
than other real-time traffic (such as RTP).
This extension will not be useful in all environments. Care needs to
be taken by any domain implementing this capability to prevent
misuse creating a means for unauthorized communications to achieve
an elevated PHB. That said, a viable use is for a service provider
who wants to grant its customers greater service than roaming
endpoints into that network.
This extension is for endpoint to endpoint session set-up and
dynamic changes of DSCPs.
1.1 Changes Since Last Version
The following are the changes since the last version of this
document was produced:
- removed all discussion of servers and intermediaries, including
how they can initiate a change in DSCP values for any streams.
- changed the ability of the answerer to change the 'dscp' attribute
in the answer, and what this means
Polk Expires Aug 2008 [Page 3]
Internet-Draft DSCP Stream Configuration in SDP Feb 2008
- cleaned up text
- fixed nits
2. SDP Attributes Definition
This document creates the 'dscp' media-level SDP [RFC4566]
attribute. The following is the ABNF syntax [RFC5234], which is
based on the SDP [RFC4566] grammar:
attribute = dscp
dscp = "dscp" *(SP dscp-value)
dscp-value = dscp-value-rtp "/" dscp-value-rtcp
SP direction-tag
dscp-value-rtp = numeric-sting / alpha-string
dscp-value-rtcp = numeric-sting / alpha-string
numeric-sting = 0-63 (limited range)
alpha-string = token
direction-tag = sendonly / recvonly / sendrecv
The dscp-value is the combination of the three parts
o a dscp-value-rtp for the RTP of a session
o a dscp-value-rtcp for the RTCP of a session
o and a direction-tag for the DSCP of RTP
The dscp-value-rtp and dscp-value-rtcp MUST each be in one of three
forms, though they both do not have to be the same form in the same
attribute
o a decimal in the range of 0 to 63
o an alpha string with the DSCP category (i.e., EF)
o or it can be a 6-bit binary sequence (i.e., 101110 for EF)
The decimal range of the dscp-value-rtp and dscp-value-rtcp is
limited to 0-63 because that is matching all the possible values as
defined in [RFC2474] for codepoints. The alpha string is the name
of the class of DSCP, compiled here.
o EF or Expedited Forwarding, as defined in [RFC3246]
o AF or Assure forwarding, as defined in [RFC2597]
o BE or Best Effort, as defined in [RFC2474]
o VOICE-ADMIT, as defined in [ID-VOICE-ADMIT]
Inclusion of the dscp-value-rtcp is OPTIONAL. Lack of the presence
of a dscp-value-rtcp in a 'dscp' attribute means the RTCP is to use
whatever is default configured in the endpoint.
If the 'dscp' attribute is present, the dscp-value-rtp MUST be
Polk Expires Aug 2008 [Page 4]
Internet-Draft DSCP Stream Configuration in SDP Feb 2008
present, and the direction-tag SHOULD be present, to ensure both
endpoints fully understand the DSCPs to use for a media level
session.
The direction-tag part of the dscp-value is to indicate which
direction this codepoint is to be used in fro the dscp-value-rtp
only, from the perspective of the endpoint generating this
attribute. An endpoint MUST be able to indicate the bi-directional
DSCP for a session. The receiver of the SDP does not have to comply
with this DSCP, but SHOULD indicate which value it intends to use.
This is not a negotiation. The offer can contain the sendrecv
direction indicator to state what DSCP it will use and what DSCP
SHOULD be indicated in the answer. If the answer does not contain a
sendrecv indication, but does have a (answer SDP) of another DSCP
value for RTP, then the original offer was accepted in the offer to
answer direction, but the answer to offer direction will use another
DSCP for RTP. If the answer did not contain a 'dscp' attribute, the
offering endpoint SHOULD consider that to indicate the answerer
either did no understand the 'dscp' attribute in the offer, or the
it will maintain using whatever DSCP is preconfigured into that
endpoint for this session.
There can be only one dscp-value per media description.
The following is an example of an "m=" line with a 'dscp' attribute:
m=audio 50001 RTP/AVP 0
a=dscp 46/16 sendrecv
The above "a=" line would set RTP packets for this stream to DSCP
46, or Expedited Forwarding (EF) as defined by [RFC3246], in both
directions (provided the answerer agreed with the direction-tag of
this attribute.
An empty "a=dscp" attribute, with no value (numeric or alpha) MAY be
present in an offer or answer to indicate support for this extension
in SDP.
3. Offer/Answer Behavior
An offer/answer exchange using the 'dscp' attribute allows endpoints
provide media packets the desired DSCP through a routed
infrastructure. Including the 'dscp' in an offer or answer
attribute is not a negotiation. This is a indication of a value to
be used as a binary DSCP in the media packets. The offerer can
include a suggestion to use the same DSCP bi-directionally. The
answerer's answer will indicate is this is acceptable or not.
Figure 1. shows this exchange,
Polk Expires Aug 2008 [Page 5]
Internet-Draft DSCP Stream Configuration in SDP Feb 2008
Alice Bob
| |
| Offer |
| a=dscp 46/16 sendrecv |
|---------------------------->|
| |
| Answer |
| a=dscp 46/16 sendrecv |
|<----------------------------|
| |
| 2-way RTP (DSCP=46 or EF) |
|<===========================>|
| |
Figure 1. Diagram setting initial DSCP Values
The following is an example of the "m=" line in Figure 1. with a
'dscp' attribute:
m=audio 50001 RTP/AVP 0
a=dscp 46/16 sendrecv
The above "a=" line would set the media packets for this stream to
Expedited Forwarding (EF) as defined by [RFC3246]. The RTCP packets
would be set to CS2 (16), or the OAM class according to [RFC4594].
The direction-tag is set to send-recv in the offer, and accepted in
the answer (because it is also indicating the same DSCP values and
in both directions).
If, at some point during the session, an endpoint wanted to change
the DSCP markings of the RTP packets within this media stream, it
could sent this offer (illustrated in Figure 2.) in both directions:
m=audio 50001 RTP/AVP 0
a=dscp 0/16 sendrecv
thereby setting this media stream to what is considered Best Effort
PHB, in both directions, while not changing the DSCP of the RTCP.
3.1 Offerer Behavior
An offerer MUST include a 'dscp' attribute in a offer, if it wants
to indicate it wants to have a particular stream have a non-default
DSCP value in one or both directions. The offerer MUST set a
direction-tag if it wants a non-default DSCP in one direction or
another. The offerer does not have to include a direction-tag if it
knows the answerer will not change the dscp-value in the answer. An
offerer SHOULD NOT assume this is always the case, and be sure and
include exactly what it wants.
An offerer receiving an answer other than a copy of what was offered
Polk Expires Aug 2008 [Page 6]
Internet-Draft DSCP Stream Configuration in SDP Feb 2008
only considers the changes to apply to what the answerer is going to
do. It MUST NOT change what the offerer is going to do. There is no
rejection of a stream based on what a DSCP is in a packet, so there
is no ill effects from this. However, the answerer can become an
offerer in an UPDATE or reINVITE (using SIP) of the same session if
they do not want either endpoint using the DSCPs offered originally.
Care SHOULD be taken that this does not occur over and over gain
during the same session, as this event occurring more than once does
not solve anything, and wastes resources.
An answer that does not contain a 'dscp' attribute when there was
one in the offer means the answerer does not support this extension.
An offerer MAY include an empty 'dscp' attribute to indicate support
for this capability.
An offerer MAY include a 'dscp' attribute in a offer for the
purposes of indicating which level of support or service the offerer
wants this session to have. Consider the case in which a customer
(the offerer) has a contract with a network that allows multiple
service levels, fr example a gold/silver/bronze package. An offerer
MAY include this 'dscp' attribute to indicate which service level
this session is desired to achieve. This allows Alice to offer to
Bob one of three different service levels of RTP to Bob, with the
5-tuple being the same for each of the sessions.
3.2 Answerer Behavior
An answerer supporting this extension MUST adhere to the 'dscp'
attribute in the offer if the offer in whole is acceptable to the
answerer. It is RECOMMENDED that the answerer reciprocate the
'dscp' attribute in the answer; meaning if the offer is
a=dscp 46/16 sendrecv
the answer SHOULD be
a=dscp 46/16 sendrecv
If the offer is
a=dscp 46/16 sendonly
and the answerer is not configured to use that DSCP, it would be
either what DSCP the answerer is configured to use for its RTP
packets with a sendonly direction-tag, or if it does not want to
inform the offerer, it can answer like this
a=dscp 46/16 recvonly
Each of these cases are acceptable according to the rules here.
Polk Expires Aug 2008 [Page 7]
Internet-Draft DSCP Stream Configuration in SDP Feb 2008
What is not acceptable for an answerer is to tell the offerer which
DSCP the offerer should use in the initial answer. This is left for
an (using SIP as an example) UPDATE or reINVITE transaction where
the answerer becomes the offerer and attempts to suggest/control the
DSCPs to be used for this particular media stream.
An endpoint that does not support this extension merely ignores the
'dscp' attribute and answers without it. An answer that does not
contain a 'dscp' attribute when there was one in the offer means the
answerer does not support this extension. A DSCP of 0 (zero) is a
valid DSCP, and MUST NOT be considered a null answer, and MUST only
be used if the endpoint wishes to set their RTP codepoints to the
"Best Effort" traffic class.
An answerer that wants to go with what the offerer has offerer
merely copies the 'dscp' attribute from the offer. If this is the
offer
a=dscp 46/16 sendrecv
this is the answer
a=dscp 46/16 sendrecv
Inclusion of the dscp-value-rtcp is OPTIONAL in this extension. If
an offerer or answerer wants to set or modify the DSCP to be used by
either endpoint, this extension MUST be used to ensure consistency.
With that said, discussion about copying the 'dscp' attribute from
offer to answer equates supporting and accepting an offer, this does
not apply to the RTCP value, which can change, and still consider
the media stream 'dscp' attribute to have been accepted via a copy.
[EDITOR's NOTE: does this make sense (that this extension is only
sensitive to RTP codepoint values and not both?)
4. Changing the 'dscp' Attribute in an Established Session
Whether or not the 'dscp' attribute was used in the initial
offer/answer exchange, either endpoint is allowed to generate offers
can change the 'dscp' attribute from a
o null (or no DSCP value in the media packets) value,
o a default uncommunicated value
o or a previously communicated 'dscp' attribute
to something (else) during a session. Maintaining compliance with
Section 3 above, here in Figure 2. is one example of a 'dscp'
attribute being changed for a media stream.
Polk Expires Aug 2008 [Page 8]
Internet-Draft DSCP Stream Configuration in SDP Feb 2008
Alice Bob
| Existing |
| 2-way RTP (DSCP=46 or EF) |
|<===========================>|
| |
| Offer |
| a=dscp 0/16 sendrecv |
|---------------------------->|
| |
| Answer |
| a=dscp 0/16 sendrecv |
|<----------------------------|
| |
| Modified |
| 2-way RTP (DSCP=0 or BE) |
|<===========================>|
| |
Figure 2. Diagram with Intermediary setting initial DSCPs
In Figure 2. there is an existing session between Alice and Bob,
when Alice's endpoint decides (however that occurs) to modify the
DSCPs of a this stream. This process starts with an offer. Figure
2. shows an existing media stream marked as EF or 46, but Alice
wants to change this to a codepoint of 0 (zero) for whatever
reason. Perhaps the call was preempted and needs to be moved into
a Best Effort class to maintain the call.
The current DSCP being used is (perhaps as if the session was
brought up as)
a=dscp 46/16 sendrecv
Alice's new offer is
a=dscp 0/16 sendrecv
If Bob answers affirmatively, this is the answer
a=dscp 0/16 sendrecv
This changes the marking of the media stream packets between the two
endpoints. This MAY be how an IMS P- or S-CSCF modifies the DSCP of
a particular session.
5. IANA Considerations
This specification registers one new media level SDP attribute in
the att-field (media level only) table.
Polk Expires Aug 2008 [Page 9]
Internet-Draft DSCP Stream Configuration in SDP Feb 2008
5.1. Registration of the SDP 'dscp' Attribute
This section instructs the IANA to register the following SDP att-
field under the Session Description Protocol (SDP) Parameters
registry:
Contact name: James Polk <jmpolk@cisco.com>, +1.817.271.3552
Attribute name: dscp
Long-form attribute name: Mechanism for Configuring the DSCP of a
Media Stream and related RTCP indication
for that stream
Type of attribute: Media level only
Subject to charset: No
Purpose of attribute: To configure a new DSCP for one or more (i.e.
possibly each) media stream within an SDP
during session establishment or session
modification, as well as each related RTCP
DSCP value
Allowed attribute values: - For DSCP of RTP, see Section 2. of this
document for details
- For DSCP of RTCP, see Section 2. of
this document for details
Reference: This document (if published)
6. Security Considerations
An attacker may attempt to add, modify, or remove the 'dscp'
attribute(s) from a session description. This could result in a
media stream receiving undesirable behavior through a network. For
example, the endpoints under attack may receive a more or less
desirable PHB.
Consequently, it is strongly RECOMMENDED that integrity protection
be applied to SDP session descriptions carrying these attributes.
For session descriptions carried in SIP [RFC3261], S/MIME [RFC3851]
is the natural choice to provide such end-to-end integrity
protection, as described in [RFC3261]. Other applications MAY use a
different form of integrity protection.
7. Open Issues
Here is a list of known open issues understood to the author as
needing to be addressed:
Polk Expires Aug 2008 [Page 10]
Internet-Draft DSCP Stream Configuration in SDP Feb 2008
#1 - This document focuses on the RTP and RTCP DSCP markings, yet
favors the RTP markings in the offer/answer exchange. Should
equal weight be given to adhering to uniformity during an
offer/answer exchange for RTCP markings?
#2 - Not sure the ABNF is right for the look of the examples, which
I believe is what is desired to convey what this extension
intends.
8. Acknowledgements
Kevin McMenamy and Subha Dhesikan helped form this effort. As well
as to Scott Brim for reviewing it. Thanks to Dan Wing, Shida
Schubert, Francois Audet, Martin Dolly, and Janet Gunn for helpful
comments, recommendations and support for this effort.
9. References
9.1 Normative References
[RFC4566] M. Handley, V. Jacobson, C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006
[RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the
Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3264] J. Rosenberg, H. Schulzrinne, "The Offer/Answer Model with
Session Description Protocol", RFC 3264, June 2002
[RFC4594] J. Babiarz, K. Chan, F Baker, "Configuration Guidelines for
Diffserv Service Classes", RFC4594, August 2006
[ID-VOICE-ADMIT] F. Baker, J. Polk, M. Dolly, "An EF DSCP for
Capacity-Admitted Traffic",
draft-ietf-tsvwg-admitted-realtime-dscp-04, "work in
progress", December 07
[RFC3246] B. Davie, A. Charny, J.C.R. Bennet, K. Benson, J.Y. Le
Boudec, W. Courtney, S. Davari, V. Firoiu, D. Stiliadis, "An
Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246,
March 2002
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
Polk Expires Aug 2008 [Page 11]
Internet-Draft DSCP Stream Configuration in SDP Feb 2008
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
DiffServ Service Classes", RFC 5127, February 2008.
9.2 Informative References
[RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control Protocol
(MGCP) Version 1.0", RFC 3435, January 2003.
[RFC3015] F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J.
Segers, "Megaco Protocol Version 1.0", RFC 3015, November
2000.
Author's Address
James Polk
3913 Treemont Circle
Colleyville, Texas 76034
USA
Phone: +1-817-271-3552
Email: jmpolk@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Polk Expires Aug 2008 [Page 12]
Internet-Draft DSCP Stream Configuration in SDP Feb 2008
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.
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 Expires Aug 2008 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-22 22:15:01 |