Internet DRAFT - draft-goldman-pcn-pstn-scope
draft-goldman-pcn-pstn-scope
Network Working Group S. Goldman
Internet-Draft
Intended status: Informational B. Schaefer
Expires: August 18, 2011 Telcordia Technologies
February 14, 2011
PSTN scope of PCN Charter
draft-goldman-pcn-pstn-scope-10.txt
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
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.
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 18, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
Goldman & Schaefer Expires August 18, 2011 [Page 1]
Internet-Draft PSTN scope of PCN Charter February 2011
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
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 & Schaefer Expires August 18, 2011 [Page 2]
Internet-Draft PSTN scope of PCN Charter February 2011
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 & Schaefer Expires August 18, 2011 [Page 3]
Internet-Draft PSTN scope of PCN Charter February 2011
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 & Schaefer Expires August 18, 2011 [Page 4]
Internet-Draft PSTN scope of PCN Charter February 2011
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 & Schaefer Expires August 18, 2011 [Page 5]
Internet-Draft PSTN scope of PCN Charter February 2011
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 & Schaefer Expires August 18, 2011 [Page 6]
Internet-Draft PSTN scope of PCN Charter February 2011
Authors' Addresses
Stuart Goldman
5531 E. Kelton Ln.
Scottsdale, AZ,85254-1111 USA
Phone: - +1 602 493 8438
EMail: familygoldman@gmail.com
Bob Schaefer
Telcordia Technologies
One Telcordia Drive, RRC-4B625
Piscataway, NJ 08854 USA
Phone: - +1 (908) 874-8513
EMail: rschaefe@telcordia.com
Goldman & Schaefer Expires August 18, 2011 [Page 7]
