PSTN scope of PCN Charter
Alcatel–Lucent
5531 E. Kelton Ln.
Scottsdale, AZ,85254-1111 USA
- +1 623 582 7136
sgoldman@alcatel-lucent.com
Verizon
2400 N Glenville Dr.
Richardson, TX 75082 USA
- +1-214-233-4473
robert.schafer@verizon.com
NATIONAL COMMUNICATIONS SYSTEM OFFICE OF THE MANAGER
245 Murray Lane
Washington, DC 20528-8500 USA
- +1-703-235-5818
frank.suraci@dhs.gov
Telcordia Technologies
One Telcordia Drive, RRC-4B625
Piscataway, NJ 08854 USA
- +1 (908) 874-8513
rschaefe@telcordia.com
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.
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
.
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
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."
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.
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.
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?
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.
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.
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?
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?
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.
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 different than general traffic so that
special consideration should be given
to controlling the traffic generated by them.
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.
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.
We would like to thank Igor Faynberg and Gary Sacra for their previous comments.
Key words for use in RFCs to Indicate Requirement Levels
Harvard University
1350 Mass. Ave.
Cambridge
MA 02138
- +1 617 495 3864
sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they MUST be interpreted in IETF documents. Authors who follow these guidelines MUST incorporate this phrase near the beginning of their document:
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 RFC 2119.
Note that the force of these words is modified by the requirement level of the document in which they are used.