Network Working Group S. Goldman Internet-Draft Alcatel-Lucent Intended status: Informational R. Schafer Expires: January 6, 2009 Verizon F. Suraci NATIONAL COMMUNICATIONS SYSTEM OFFICE OF THE MANAGER B. Schaefer Telcordia Technologies July 5, 2008 PSTN scope of PCN Charter draft-goldman-pcn-pstn-scope-03.txt 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 January 6, 2009. Abstract The IETF PCN Working Group has continued its work investigating pre- congestion and admission control mechanisms. This work has progressed under the current charter, but has not yet considered related legacy PSTN interactions or the need for ubiquitous connectivity between users on dissimilar networks. The PCN charter could be improved by a strong positive statement to the effect Goldman, et al. Expires January 6, 2009 [Page 1] Internet-Draft PSTN scope of PCN Charter July 2008 committing to future work addressing legacy networks. In that light, please consider the questions below which include differential PCN treatment based on traffic types, security, and PSTN interoperability concerns. It seems helpful to have a touchstone of some concerns relative to the PSTN network and IP network Gateway in order to confirm that they will be addressed in future work. This attempt is motivated by a desire to avoid the accidental omission of a topic that may be hard to "retrofit" in later. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Differential PCN Treatment based on Types of Traffic . . . . . 4 4. PSTN Interoperability Concerns . . . . . . . . . . . . . . . . 4 4.1. Considerations Regarding Traffic Offered from the PSTN Gateway toward the Core . . . . . . . . . . . . . . . . . . 4 4.1.1. Gateway reliance on PCN messages from the core . . . . 4 4.1.2. Traditional Network Management . . . . . . . . . . . . 4 4.1.3. Mass Calling . . . . . . . . . . . . . . . . . . . . . 5 4.1.4. Hard to reach . . . . . . . . . . . . . . . . . . . . . 5 4.2. Considerations Regarding Traffic Offered to the PSTN Gateway from the Core . . . . . . . . . . . . . . . . . . . 5 4.2.1. Gateway sending PCN messages to the core . . . . . . . 5 4.2.2. Traditional Network Management . . . . . . . . . . . . 5 4.2.3. Mass Calling . . . . . . . . . . . . . . . . . . . . . 5 4.2.4. Hard to reach . . . . . . . . . . . . . . . . . . . . . 5 5. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Goldman, et al. Expires January 6, 2009 [Page 2] Internet-Draft PSTN scope of PCN Charter July 2008 1. Requirements notation 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] . 2. Introduction Experience in the legacy PSTN (Public Switched Telephone Network) and associated network management has taught that there are certain types of traffic that should be addressed differently than POTS (Plain Old Telephone Service). Examples are mass calling events and auto dialers. For the foreseeable future the legacy PSTN will co-exist with the newer IP based networks. Is there a need that Pre-congestion and congestion signaling be sent from the core to gateways into the PSTN? Similarly is there a need for PSTN gateways to inform the IP core of congestion within the PSTN? While these concerns may not be within scope of the initial PCN charter, it may be worthwhile to address if such needs do exist and if so, what would be the best course of action for the PCN working group. The charter discusses ingress and egress nodes but does not explicitly discuss the situation where these nodes may be gateways to the PSTN. Is there a belief that the interconnection to the legacy PSTN can be treated as an edge, or the same as the interconnection between two IP based networks, or is there sufficient reason to believe that this interface may have unique characteristics that need to be specifically addressed? Given that a significant portion of the legacy equipment in the PSTN is less likely to evolve to specially address unique aspects of interconnection with IP based networks, it seems that one significant constraint on the industry would be that any adaptation needed to work with PCN would need to occur at the PSTN gateways and need to be encompassed in the characteristics of the PCN mechanisms. The trust model in the legacy PSTN model may differ fundamentally from that in the interconnection of IP based networks. We have not yet researched such characteristics, but feel the question should at least be raised here. We understand that these concerns may be out of scope of the initial work as it extends beyond a single domain, but may be addressed in future work as indicated by the text below from the charter. "After completion of the initial phase, the PCN WG may re-charter to develop solutions for scenarios where some of these restrictions are not in place. It may also re-charter to consider applying the PCN Goldman, et al. Expires January 6, 2009 [Page 3] Internet-Draft PSTN scope of PCN Charter July 2008 mechanisms to additional deployment scenarios (operation over concatenated DiffServ domains, PCN-aware application mechanisms, etc.). The WG may also consider to investigate additional response mechanisms that act on (pre-)congestion information. One example could be flow-rate adaptation (rather than flow admission/ termination) during times of congestion. The details of these work items are outside the scope of the initial phase; but the WG may consider their requirements to design components that are sufficiently general to support such extensions in the future." 3. Differential PCN Treatment based on Types of Traffic As we understand the PCN operation, it would be the responsibility of the ingress nodes to control the offered traffic and it would be outside the scope of the initial charter to address exactly how this control should be applied. Nevertheless it does seem to be helpful for understanding if the charter could at least provide recognition of mass calling events, auto dialers, and other non-"POTS" traffic types. The charter should provide guidance that the ingress node may address these traffic types separately. 4. PSTN Interoperability Concerns 4.1. Considerations Regarding Traffic Offered from the PSTN Gateway toward the Core 4.1.1. Gateway reliance on PCN messages from the core Is it reasonable for the PSTN gateway to rely on the IP network to send sufficient PCN messages to the gateway allowing the gateway to then limit the traffic its sends into the core? Conversely, can the core rely on the PSTN gateways to be responsive to PCN messages? Unless these concerns are eventually addressed, it would appear that PCN may not be as effective in this configuration as would be possible. 4.1.2. Traditional Network Management Should the PSTN and gateway also explore more traditional network management controls to prevent exceeding the allocated traffic offered to the core? Unless such exploration occurs PCN may not be as effective in this configuration as would be possible. Should the PSTN and gateway also provide exemptions to traditional network management controls for high priority calls? Goldman, et al. Expires January 6, 2009 [Page 4] Internet-Draft PSTN scope of PCN Charter July 2008 4.1.3. Mass Calling Will there be any consideration of using PCN messages to control Mass Calling Events from the PSTN into the core? Mass Calling Events are significantly different than general traffic so that special consideration should be given to controlling the traffic generated by them. 4.1.4. Hard to reach Will there be any consideration of using PCN messages to control sending traffic to hard to reach destinations (hard to reach codes) into the core? Hard to reach destinations are significantly different than general traffic so that special consideration should be given to controlling the traffic generated by them. 4.2. Considerations Regarding Traffic Offered to the PSTN Gateway from the Core 4.2.1. Gateway sending PCN messages to the core Should there be a consideration for the PTSN gateway to be able to send PCN messages toward the core when the PSTN is in precongestion or congestion? 4.2.2. Traditional Network Management Should the PSTN and gateway also explore more traditional network management controls to control the traffic being passed on to the PSTN from the gateway so as to not exceed the allocated traffic offered to the PSTN network? Should the PSTN and gateway also provide exemptions to traditional network management controls for high priority calls? 4.2.3. Mass Calling Will there be any consideration of using PCN messages to control Mass Calling Events to the PSTN from the core? Mass Calling Events are significantly different than general traffic so that special consideration should be given to controlling the traffic generated by them. 4.2.4. Hard to reach Will there be any consideration of using PCN messages to control sending traffic to hard to reach destinations (hard to reach codes) into the PSTN? Hard to reach destinations are significantly Goldman, et al. Expires January 6, 2009 [Page 5] Internet-Draft PSTN scope of PCN Charter July 2008 different than general traffic so that special consideration should be given to controlling the traffic generated by them. 5. Proposal It does seem to be helpful for understanding if the charter could at least provide recognition of mass calling events, auto dialers, and other non-"POTS" traffic types. the charter should provide guidance that the ingress node may address these separately. Given the reality that the legacy PSTN will continue to exist for a considerable period of time, and the need for ubiquitous connectivity between users on the dissimilar networks, it seems to us that the charter could be improved by a strong positive statement to the effect committing to future work to address the unique aspects of PCN with regard to legacy networks as well as having this constraint in mind during the work under the initial charter. 6. Security Considerations Traffic can be disrupted if malicious PCN messages are sent. The potential of a denial of service attack exists in that fraudulent PCN messages could result in a considerable percentage of legitimate subscriber traffic being blocked. At this point it appears that there is corresponding risk in both the IP networks and the legacy PSTN. 7. IANA Considerations None. 8. Acknowledgement We would like to thank Igor Faynberg and Gary Sacra for their previous comments. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Goldman, et al. Expires January 6, 2009 [Page 6] Internet-Draft PSTN scope of PCN Charter July 2008 Authors' Addresses Stuart Goldman Alcatel-Lucent 5531 E. Kelton Ln. Scottsdale, AZ,85254-1111 USA Phone: - +1 623 582 7136 EMail: sgoldman@alcatel-lucent.com Robert Schafer Verizon 2400 N Glenville Dr. Richardson, TX 75082 USA Phone: - +1-214-233-4473 EMail: robert.schafer@verizon.com Frank Suraci NATIONAL COMMUNICATIONS SYSTEM OFFICE OF THE MANAGER 245 Murray Lane Washington, DC 20528-8500 USA Phone: - +1-703-235-5818 EMail: frank.suraci@dhs.gov Bob Schaefer Telcordia Technologies One Telcordia Drive, RRC-4B625 Piscataway, NJ 08854 USA Phone: - +1 (908) 874-8513 EMail: rschaefe@telcordia.com Goldman, et al. Expires January 6, 2009 [Page 7] Internet-Draft PSTN scope of PCN Charter July 2008 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. 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. Acknowledgement This document was produced using xml2rfc v1.33 (of http://xml.resource.org/) from a source in RFC-2629 XML format. Goldman, et al. Expires January 6, 2009 [Page 8]