Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)
RFC 4666
| Document | Type |
RFC
- Proposed Standard
(September 2006)
Errata
IPR
Obsoletes RFC 3332
|
|
|---|---|---|---|
| Authors | Javier Pastor , Ken Morneault | ||
| Last updated | 2015-10-14 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Jon Peterson | |
| Send notices to | (None) |
RFC 4666
Internet Area WG J. Touch
Internet Draft USC/ISI
Updates: 791,1122,2003 May 30, 2012
Intended status: Proposed Standard
Expires: November 2012
Updated Specification of the IPv4 ID Field
draft-ietf-intarea-ipv4-id-update-05.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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 November 30, 2012.
Touch Expires November 30, 2012 [Page 1]
Internet-Draft Updated Spec. of the IPv4 ID Field May 2012
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
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.
Abstract
The IPv4 Identification (ID) field enables fragmentation and
reassembly, and as currently specified is required to be unique
within the maximum lifetime for all datagrams with a given
source/destination/protocol tuple. If enforced, this uniqueness
requirement would limit all connections to 6.4 Mbps. Because
individual connections commonly exceed this speed, it is clear that
existing systems violate the current specification. This document
updates the specification of the IPv4 ID field in RFC791, RFC1122,
and RFC2003 to more closely reflect current practice and to more
closely match IPv6 so that the field's value is defined only when a
datagram is actually fragmented. It also discusses the impact of
these changes on how datagrams are used.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................3
3. The IPv4 ID Field..............................................4
4. Uses of the IPv4 ID Field......................................4
5. Background on IPv4 ID Reassembly Issues........................5
6. Updates to the IPv4 ID Specification...........................6
6.1. IPv4 ID Used Only for Fragmentation.......................7
6.2. Encourage Safe IPv4 ID Use................................8
6.3. IPv4 ID Requirements That Persist.........................8
7. Impact on Datagram Use.........................................9
8. Updates to Existing Standards..................................9
8.1. Updates to RFC 791.......................................10
8.2. Updates to RFC 1122......................................10
8.3. Updates to RFC 2003......................................11
Touch Expires November 30, 2012 [Page 2]
Internet-Draft Updated Spec. of the IPv4 ID Field May 2012
9. Impact on Middleboxes.........................................11
9.1. Rewriting Middleboxes....................................12
9.2. Filtering Middleboxes....................................13
10. Impact on Header Compression.................................13
11. Security Considerations......................................13
12. IANA Considerations..........................................14
13. References...................................................14
13.1. Normative References....................................14
13.2. Informative References..................................14
14. Acknowledgments..............................................16
1. Introduction
In IPv4, the Identification (ID) field is a 16-bit value that is
unique for every datagram for a given source address, destination
address, and protocol, such that it does not repeat within the
Maximum Segment Lifetime (MSL) [RFC791][RFC1122]. As currently
specified, all datagrams between a source and destination of a given
protocol must have unique IPv4 ID values over a period of this MSL,
which is typically interpreted as two minutes (120 seconds). This
uniqueness is currently specified as for all datagrams, regardless of
fragmentation settings.
Uniqueness of the IPv4 ID is commonly violated by high speed devices;
if strictly enforced, it would limit the speed of a single protocol
between two IP endpoints to 6.4 Mbps for typical MTUs of 1500 bytes
[RFC4963]. It is common for a single connection to operate far in
excess of these rates, which strongly indicates that the uniqueness
of the IPv4 ID as specified is already moot.
This document updates the specification of the IPv4 ID field to more
closely reflect current practice, and to include considerations taken
into account during the specification of the similar field in IPv6.
2. Conventions used in this 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 [RFC2119].
In this document, the characters ">>" proceeding an indented line(s)
indicates a requirement using the key words listed above. This
convention aids reviewers in quickly identifying or finding this
document's explicit requirements.
Touch Expires November 30, 2012 [Page 3]
Internet-Draft Updated Spec. of the IPv4 ID Field May 2012
3. The IPv4 ID Field
IP supports datagram fragmentation, where large datagrams are split
into smaller components to traverse links with limited maximum
transmission units (MTUs). Fragments are indicated in different ways
in IPv4 and IPv6:
o In IPv4, fragments are indicated using four fields of the basic
header: Identification (ID), Fragment Offset, a "Don't Fragment"
flag (DF), and a "More Fragments" flag (MF) [RFC791]
o In IPv6, fragments are indicated in an extension header that
includes an ID, Fragment Offset, and M (more fragments) flag
similar to their counterparts in IPv4 [RFC2460]
IPv4 and IPv6 fragmentation differs in a few important ways. IPv6
fragmentation occurs only at the source, so a DF bit is not needed to
prevent downstream devices from initiating fragmentation (i.e., IPv6
always acts as if DF=1). The IPv6 fragment header is present only
when a datagram has been fragmented, or when the source has received
a "packet too big" ICMPv6 error message when the path cannot support
the required minimum 1280-byte IPv6 MTU and is thus subject to
translation [RFC2460][RFC4443]. The latter case is relevant only for
IPv6 datagrams sent to IPv4 destinations to support subsequent
fragmentation after translation to IPv4.
With the exception of these two cases, the ID field is not present
for non-fragmented datagrams, and thus is meaningful only for
datagrams that are already fragmented or datagrams intended to be
fragmented as part of IPv4 translation. Finally, the IPv6 ID field is
32 bits, and required unique per source/destination address pair for
IPv6, whereas for IPv4 it is only 16 bits and required unique per
source/destination/protocol triple.
This document focuses on the IPv4 ID field issues, because in IPv6
the field is larger and present only in fragments.
4. Uses of the IPv4 ID Field
The IPv4 ID field was originally intended for fragmentation and
reassembly [RFC791]. Within a given source address, destination
address, and protocol, fragments of an original datagram are matched
based on their IPv4 ID. This requires that IDs are unique within the
address/protocol triple when fragmentation is possible (e.g., DF=0)
or when it has already occurred (e.g., frag_offset>0 or MF=1).
Touch Expires November 30, 2012 [Page 4]
Internet-Draft Updated Spec. of the IPv4 ID Field May 2012
The IPv4 ID field can be useful for other purposes. The field has
been proposed as a way to detect and remove duplicate datagrams,
e.g., at congested routers (noted in Sec. 3.2.1.5 of [RFC1122]) or in
network accelerators. It can similarly be used at end hosts to reduce
the impact of duplication on higher-layer protocols (e.g., additional
processing in TCP, or the need for application-layer duplicate
suppression in UDP).
The IPv4 ID field is also used in some debugging tools to correlate
datagrams measured at various locations along a network path. This is
already insufficient in IPv6 because unfragmented datagrams lack an
ID, so these tools are already being updated to avoid such reliance
on the ID field.
The ID clearly needs to be unique (within MSL, within the
src/dst/protocol tuple) to support fragmentation and reassembly, but
not all datagrams are fragmented or allow fragmentation. This
document deprecates non-fragmentation uses, allowing the ID to be
repeated (within MSL, within the src/dst/protocol tuple) in those
cases.
5. Background on IPv4 ID Reassembly Issues
The following is a summary of issues with IPv4 fragment reassembly in
high speed environments raised previously [RFC4963]. Readers are
encouraged to consult RFC 4963 for a more detailed discussion of
these issues.
With the maximum IPv4 datagram size of 64KB, a 16-bit ID field that
does not repeat within 120 seconds means that the aggregate of all
TCP connections of a given protocol between two IP endpoints is
limited to roughly 286 Mbps; at a more typical MTU of 1500 bytes,
this speed drops to 6.4 Mbps [RFC791][RFC1122][RFC4963]. This limit
currently applies for all IPv4 datagrams within a single protocol
(i.e., the IPv4 protocol field) between two IP addresses, regardless
of whether fragmentation is enabled or inhibited, and whether a
datagram is fragmented or not.
IPv6, even at typical MTUs, is capable of 18.7 Tbps with
fragmentation between two IP endpoints as an aggregate across all
protocols, due to the larger 32-bit ID field (and the fact that the
IPv6 next-header field, the equivalent of the IPv4 protocol field, is
not considered in differentiating fragments). When fragmentation is
not used the field is absent, and in that case IPv6 speeds are not
limited by the ID field uniqueness.
Touch Expires November 30, 2012 [Page 5]
Internet-Draft Updated Spec. of the IPv4 ID Field May 2012
Note also that 120 seconds is only an estimate on the maximum
datagram lifetime. It is loosely based on half maximum value of the
IP TTL field (255), measured in seconds, because the TTL was
originally specified as decremented not only for each hop, but also
for each second a datagram is held at a router (as implied in
[RFC791], although this has long since become a hopcount only).
Network delays are incurred in other ways, e.g., satellite links,
which can add seconds of delay even though the TTL is not decremented
by a corresponding amount. There is thus no enforcement mechanism to
ensure that datagrams older than 120 seconds are discarded.
Wireless Internet devices are frequently connected at speeds over 54
Mbps, and wired links of 1 Gbps have been the default for several
years. Although many end-to-end transport paths are congestion
limited, these devices easily achieve 100+ Mbps application-layer
throughput over LANs (e.g., disk-to-disk file transfer rates), and
numerous throughput demonstrations with COTS systems over wide-area
paths exhibit these speeds for over a decade. This strongly suggests
that IPv4 ID uniqueness has been moot for a long time.
6. Updates to the IPv4 ID Specification
This document updates the specification of the IPv4 ID field in three
distinct ways, as discussed in subsequent subsections:
o Use the IPv4 ID field only for fragmentation
o Avoiding a performance impact when the IPv4 ID field is used
o Encourage safe operation when the IPv4 ID field is used
There are two kinds of datagrams used in the following discussion,
named as follows:
o Atomic datagrams are datagrams not yet fragmented and for which
further fragmentation has been inhibited.
o Non-atomic datagrams are datagrams which either have already been
fragmented or for which fragmentation remains possible.
This same definition can be expressed in pseudo code as using common
logical operators (equals is ==, logical 'and' is &&, logical 'or' is
||, greater than is >, and parenthesis function typically) as:
o Atomic datagrams: (DF==1)&&(MF==0)&&(frag_offset==0)
o Non-atomic datagrams: (DF==0)||(MF==1)||(frag_offset>0)
Touch Expires November 30, 2012 [Page 6]
Internet-Draft Updated Spec. of the IPv4 ID Field May 2012
The test for non-atomic datagrams is the logical negative of the test
for atomic datagrams, thus all possibilities are considered.
6.1. IPv4 ID Used Only for Fragmentation
Although RFC1122 suggests the IPv4 ID field has other uses, including
datagram de-duplication, this document asserts that this field's
value is defined only for fragmentation and reassembly:
>> IPv4 ID field MUST NOT be used for purposes other than
fragmentation and reassembly.
Datagram de-duplication can be accomplished using hash-based
duplicate detection for cases where the ID field is absent.
In atomic datagrams, the IPv4 ID field has no meaning, and thus can
be set to an arbitrary value, i.e., the requirement for non-repeating
IDs within the address/protocol triple is no longer required for
atomic datagrams:
>> Originating sources MAY set the IPv4 ID field of atomic datagrams
to any value.
Second, all network nodes, whether at intermediate routers,
destination hosts, or other devices (e.g., NATs and other address
sharing mechanisms, firewalls, tunnel egresses), cannot rely on the
field:
>> All devices that examine IPv4 headers MUST ignore the IPv4 ID
field of atomic datagrams.
The IPv4 ID field is thus meaningful only for non-atomic datagrams -
datagrams that have either already been fragmented, or those for
which fragmentation remains permitted. Atomic datagrams are detected
by their DF, MF, and fragmentation offset fields as explained in
Section 6, because such a test is completely backward compatible;
this document thus does not reserve any IPv4 ID values, including 0,
as distinguished.
Deprecating the use of the IPv4 ID field for non-reassembly uses
should have little - if any - impact. IPv4 IDs are already frequently
repeated, e.g., over even moderately fast connections. Duplicate
suppression was only suggested [RFC1122], and no impacts of IPv4 ID
reuse have been noted. Routers are not required to issue ICMPs on any
particular timescale, and so IPv4 ID repetition should not have been
used for validation, and again repetition occurs and probably could
have been noticed [RFC1812]. ICMP relaying at tunnel ingresses is
Touch Expires November 30, 2012 [Page 7]
Internet-Draft Updated Spec. of the IPv4 ID Field May 2012
specified to use soft state rather than a datagram cache, and should
have been noted if the latter for similar reasons [RFC2003].
6.2. Encourage Safe IPv4 ID Use
This document makes further changes to the specification of the IPv4
ID field and its use to encourage its safe use as corollary
requirements changes as follows.
RFC 1122 discusses that if TCP retransmits a segment it may be
possible to reuse the IPv4 ID (see Section 8.2). This can make it
difficult for a source to avoid IPv4 ID repetition for received
fragments. RFC 1122 concludes that this behavior "is not useful";
this document formalizes that conclusion as follows:
>> The IPv4 ID of non-atomic datagrams MUST NOT be reused when
sending a copy of an earlier non-atomic datagram.
RFC 1122 also suggests that fragments can overlap [RFC1122]. Such
overlap can occur if successive retransmissions are fragmented in
different ways but with the same reassembly IPv4 ID. This overlap is
noted as the result of reusing IPv4 IDs when retransmitting
datagrams, which this document deprecates. However, it is also the
result of in-network datagram duplication, which can still occur. As
a result this document does not change the need to support
overlapping fragments.
6.3. IPv4 ID Requirements That Persist
This document does not relax the IPv4 ID field uniqueness
requirements of [RFC791] for non-atomic datagrams, i.e.:
>> Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID
values within one MSL for a given source address/destination
address/protocol triple.
Such sources include originating hosts, tunnel ingresses, and NATs
(including other address sharing mechanisms) (see Section 9).
This document does not relax the requirement that all network devices
honor the DF bit, i.e.:
>> IPv4 datagrams whose DF=1 MUST NOT be fragmented.
>> IPv4 datagram transit devices MUST NOT clear the DF bit.
Touch Expires November 30, 2012 [Page 8]
Internet-Draft Updated Spec. of the IPv4 ID Field May 2012
In specific, DF=1 prevents fragmenting atomic datagrams. DF=1 also
prevents further fragmenting received fragments. In-network
fragmentation is permitted only when DF=0; this document does not
change that requirement.
7. Impact on Datagram Use
The following is a summary of the recommendations that are the result
of the previous changes to the IPv4 ID field specification.
Because atomic datagrams can use arbitrary IPv4 ID values, the ID
field no longer imposes a performance impact in those cases. However,
the performance impact remains for non-atomic datagrams. As a result:
>> Sources of non-atomic IPv4 datagrams MUST rate-limit their output
to comply with the ID uniqueness requirements.
Such sources include, in particular, DNS over UDP [RFC2671].
Because there is no strict definition of the MSL, reassembly hazards
exist regardless of the IPv4 ID reuse interval or the reassembly
timeout. As a result:
>> Higher layer protocols SHOULD verify the integrity of IPv4
datagrams, e.g., using a checksum or hash that can detect reassembly
errors (the UDP checksum is weak in this regard, but better than
nothing), as in SEAL [RFC5320].
Additional integrity checks can be employed using tunnels, as in
SEAL, IPsec, or SCTP [RFC4301][RFC4960][RFC5320]. Such checks can
avoid the reassembly hazards that can occur when using UDP and TCP
checksums [RFC4963], or when using partial checksums as in UDP-Lite
[RFC3828]. Because such integrity checks can avoid the impact of
reassembly errors:
>> Sources of non-atomic IPv4 datagrams using strong integrity checks
MAY reuse the ID within MSL values smaller than is typical.
Note, however, that such frequent reuse can still result in corrupted
reassembly and poor throughput, although it would not propagate
reassembly errors to higher layer protocols.
8. Updates to Existing Standards
The following sections address the specific changes to existing
protocols indicated by this document.
Touch Expires November 30, 2012 [Page 9]
Internet-Draft Updated Spec. of the IPv4 ID Field May 2012
8.1. Updates to RFC 791
RFC 791 states that:
The originating protocol module of an internet datagram sets the
identification field to a value that must be unique for that
source-destination pair and protocol for the time the datagram
will be active in the internet system.
And later that:
Thus, the sender must choose the Identifier to be unique for this
source, destination pair and protocol for the time the datagram
(or any fragment of it) could be alive in the internet.
It seems then that a sending protocol module needs to keep a table
of Identifiers, one entry for each destination it has communicated
with in the last maximum datagram lifetime for the internet.
However, since the Identifier field allows 65,536 different
values, some host may be able to simply use unique identifiers
independent of destination.
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same
identifier as the original transmission since fragments of either
datagram could be used to construct a correct TCP segment.
This document changes RFC 791 as follows:
o IPv4 ID uniqueness applies to only non-atomic datagrams.
o Retransmitted non-atomic IPv4 datagrams are no longer permitted to
reuse the ID value.
8.2. Updates to RFC 1122
RFC 1122 states that:
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
Touch Expires November 30, 2012 [Page 10]
Morneault & Pastor-Balbas Standards Track [Page 98]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
5.1.1.2. Single ASP in Application Server ("1+0" Sparing),
Dynamic Registration
This scenario is the same as for 5.1.1.1 but with the optional
exchange of registration information. In this case, the Registration
is accepted by the SGP.
SGP ASP1
| |
|<------------ASP Up------------|
|----------ASP Up Ack---------->|
| |
| |
|<----REGISTER REQ(LRCn,RKn)----| LRC: Local Routing
| | Key Id
|----REGISTER RESP(LRCn,RCn)--->| RK: Routing Key
| | RC: Routing Context
|----NTFY(AS-INACTIVE)(RCn)---->|
| |
| |
|<------- ASP Active(RCn)-------|
|-----ASP Active Ack (RCn)----->|
| |
|-----NTFY(AS-ACTIVE)(RCn)----->|
| |
Note: In the case of an unsuccessful registration attempt (e.g.,
invalid RKn), the Register Response message will contain an
unsuccessful indication, and the ASP will not subsequently send an
ASP Active message.
Morneault & Pastor-Balbas Standards Track [Page 99]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
5.1.1.3. Single ASP in Multiple Application Servers (Each
with "1+0" Sparing), Dynamic Registration (Case 1 - Multiple
Registration Requests)
SGP ASP1
| |
|<------------ASP Up------------|
|----------ASP Up Ack---------->|
| |
|<----REGISTER REQ(LRC1,RK1)----| LRC: Local Routing
| | Key Id
|----REGISTER RESP(LRC1,RC1)--->| RK: Routing Key
| | RC: Routing Context
|---NOTIFY(AS-INACTIVE)(RC1)--->|
| |
| |
|<------- ASP Active(RC1)-------|
|-----ASP Active Ack (RC1)----->|
| |
|----NOTIFY(AS-ACTIVE)(RC1)---->|
| |
~ ~
| |
|<----REGISTER REQ(LRCn,RKn)----|
| |
|----REGISTER RESP(LRCn,RCn)--->|
| |
|---NOTIFY(AS-INACTIVE)(RCn)--->|
| |
|<------- ASP Active(RCn)-------|
|-----ASP Active Ack (RCn)----->|
| |
|----NOTIFY(AS-ACTIVE)(RCn)---->|
| |
Note: In the case of an unsuccessful registration attempt (e.g.,
invalid RKn), the Register Response message will contain an
unsuccessful indication, and the ASP will not subsequently send an
ASP Active message. Each LRC/RK pair registration is considered
independently.
It is not necessary to follow a Registration Request/Response message
pair with an ASP Active message before sending the next Registration
Request. The ASP Active message can be sent at any time after the
related successful registration.
Morneault & Pastor-Balbas Standards Track [Page 100]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
5.1.1.4. Single ASP in Multiple Application Servers (each
with "1+0" sparing), Dynamic Registration (Case 2 - Single
Registration Request)
SGP ASP1
| |
|<------------ASP Up------------|
|----------ASP Up Ack---------->|
| |
| |
|<---REGISTER REQ({LRC1,RK1}, |
| ..., |
| {LRCn,RKn}),--|
| |
|---REGISTER RESP({LRC1,RC1},-->|
| ..., |
| (LRCn,RCn}) |
| |
|--NTFY(AS-INACTIVE)(RC1..RCn)->|
| |
| |
|<------- ASP Active(RC1)-------|
|-----ASP Active Ack (RC1)----->|
| |
|----NOTIFY(AS-ACTIVE)(RC1)---->|
| |
: :
: :
| |
|<------- ASP Active(RCn)-------|
|-----ASP Active Ack (RCn)----->|
| |
|----NOTIFY(AS-ACTIVE)(RCn)---->|
| |
Note: In the case of an unsuccessful registration attempt (e.g.,
Invalid RKn), the Register Response message will contain an
unsuccessful indication, and the ASP will not subsequently send an
ASP Active message. Each LRC/RK pair registration is considered
independently.
The ASP Active message can be sent at any time after the related
successful registration and may have more than one RC.
Morneault & Pastor-Balbas Standards Track [Page 101]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
5.1.2. Two ASPs in Application Server ("1+1" Sparing)
This scenario shows example M3UA message flows for the establishment
of traffic between an SGP and two ASPs in the same Application
Server, where ASP1 is configured to be in the ASP-ACTIVE state and
ASP2 is to be a "backup" in the event of communication failure or the
withdrawal from service of ASP1. ASP2 may act as a hot, warm, or
cold backup, depending on the extent to which ASP1 and ASP2 share
call/transaction state or can communicate call state under
failure/withdrawal events. The example message flow is the same
whether the ASP Active messages indicate "Override", "Loadshare", or
"Broadcast" mode, although typically this example would use an
Override mode.
SGP ASP1 ASP2
| | |
|<--------ASP Up---------| |
|-------ASP Up Ack------>| |
| | |
|--NOTIFY(AS-INACTIVE)-->| |
| | |
|<----------------------------ASP Up----------------|
|----------------------------ASP Up Ack------------>|
| | |
|--------------------------NOTIFY(AS-INACTIVE)----->|
| | |
| | |
|<-------ASP Active------| |
|------ASP Active Ack--->| |
| | |
|---NOTIFY(AS-ACTIVE)--->| |
|--------------------------NOTIFY(AS-ACTIVE)------->|
| | |
Morneault & Pastor-Balbas Standards Track [Page 102]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
5.1.3. Two ASPs in an Application Server ("1+1" Sparing,
Loadsharing Case)
This scenario shows a case similar to Section 5.1.2, but where the
two ASPs are brought to the state ASP-ACTIVE and subsequently
loadshare the traffic. In this case, one ASP is sufficient to handle
the total traffic load.
SGP ASP1 ASP2
| | |
|<---------ASP Up--------| |
|--------ASP Up Ack----->| |
| | |
|--NOTIFY(AS-INACTIVE)-->| |
| | |
|<-----------------------------ASP Up---------------|
|----------------------------ASP Up Ack------------>|
| | |
|--------------------------NOTIFY(AS-INACTIVE)----->|
| | |
|<--ASP Active (Ldshr)---| |
|-----ASP-Active Ack---->| |
| | |
|---NOTIFY (AS-ACTIVE)-->| |
|-----------------------------NOTIFY(AS-ACTIVE)---->|
| | |
|<---------------------------ASP Active (Ldshr)-----|
|------------------------------ASP Active Ack------>|
| | |
Morneault & Pastor-Balbas Standards Track [Page 103]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
5.1.4. Three ASPs in an Application Server ("n+k" Sparing,
Loadsharing Case)
This scenario shows example M3UA message flows for the establishment
of traffic between an SGP and three ASPs in the same Application
Server, where two of the ASPs are brought to the state ASP-ACTIVE and
subsequently share the load. In this case, a minimum of two ASPs are
required to handle the total traffic load (2+1 sparing).
SGP ASP1 ASP2 ASP3
| | | |
|<------ASP Up------| | |
|-----ASP Up Ack--->| | |
| | | |
|NTFY(AS-INACTIVE)->| | |
| | | |
|<-------------------------ASP Up-------| |
|------------------------ASP Up Ack---->| |
| | | |
|------------------NOTIFY(AS-INACTIVE)->| |
| | | |
|<--------------------------------------------ASP Up--------|
|--------------------------------------------ASP Up Ack---->|
| | | |
|--------------------------------------NOTIFY(AS-INACTIVE)->|
| | | |
| | | |
|<--ASP Act (Ldshr)-| | |
|----ASP Act Ack--->| | |
| | | |
| | | |
|<-------------------ASP Act. (Ldshr)---| |
|----------------------ASP Act Ack----->| |
| | | |
|--NTFY(AS-ACTIVE)->| | |
|--------------------NOTIFY(AS-ACTIVE)->| |
|----------------------------------------NOTIFY(AS-ACTIVE)->|
| | | |
| | | |
Morneault & Pastor-Balbas Standards Track [Page 104]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
5.2. ASP Traffic Failover Examples
5.2.1. 1+1 Sparing, Withdrawal of ASP, Backup Override
Following from the example in Section 5.1.2, ASP1 withdraws from
service:
SGP ASP1 ASP2
| | |
|<-----ASP Inactive------| |
|----ASP Inactive Ack--->| |
| | |
|----NTFY(AS-PENDING)--->| |
|-----------------------NTFY(AS-PENDING)----------->|
| | |
|<----------------------------- ASP Active----------|
|-----------------------------ASP Active Ack------->|
| | |
|----NTFY(AS-ACTIVE)---->| |
|-----------------------NTFY(AS-ACTIVE)------------>|
Note: If the SGP M3UA layer detects the loss of the M3UA peer (e.g.,
M3UA heartbeat loss or detection of SCTP failure), the initial ASP
Inactive message exchange (i.e., SGP to ASP1) would not occur.
5.2.2. 1+1 Sparing, Backup Override
Following on from the example in Section 5.1.2, ASP2 wishes to
Override ASP1 and take over the traffic:
SGP ASP1 ASP2
| | |
|<----------------------------- ASP Active----------|
|------------------------------ASP Active Ack------>|
|----NTFY(Alt ASP-Act)-->| |
| | |
Morneault & Pastor-Balbas Standards Track [Page 105]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
5.2.3. n+k Sparing, Loadsharing Case, Withdrawal of ASP
Following from the example in Section 5.1.4, ASP1 withdraws from
service:
SGP ASP1 ASP2 ASP3
| | | |
|<----ASP Inact.----| | |
|---ASP Inact Ack-->| | |
| | | |
|--NTFY(Ins. ASPs)->| | |
|---------------------------------------NOTIFY(Ins. ASPs)-->|
| | | |
| | | |
|<----------------------------------------ASP Act (Ldshr)---|
|------------------------------------------ASP Act (Ack)--->|
| | | |
|-NTFY(AS-ACTIVE)-->| | |
|-------------------NOTIFY(AS-ACTIVE)-->| |
|---------------------------------------NOTIFY(AS-ACTIVE)-->|
| | | |
| | | |
For the Notify message to be sent, the SG maintains knowledge of the
minimum ASP resources required (e.g., if the SG knows that "n+k" =
"2+1" for a Loadshare AS and "n" currently equals "1").
Note: If the SGP detects loss of the ASP1 M3UA peer (e.g., M3UA
heartbeat loss or detection of SCTP failure), the initial ASP
Inactive message exchange (i.e., SGP-ASP1) would not occur.
5.3. Normal Withdrawal of an ASP from an Application Server
and Teardown of an Association
An ASP that is now confirmed in the state ASP-INACTIVE (i.e., the ASP
has received an ASP Inactive Ack message) may now proceed to the
ASP-DOWN state, if it is to be removed from service. Following from
Section 5.2.1 or 5.2.3, where ASP1 has moved to the "Inactive" state:
Morneault & Pastor-Balbas Standards Track [Page 106]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
SGP ASP1
| |
|<-----ASP Inactive (RCn)------| RC: Routing Context
|----ASP Inactive Ack (RCn)--->|
| |
|<-----DEREGISTER REQ(RCn)-----| See Notes
| |
|---DEREGISTER RESP(LRCn,RCn)->|
| |
: :
| |
|<-----------ASP Down----------|
|---------ASP Down Ack-------->|
| |
Note: The Deregistration procedure will typically be used if the ASP
previously used the Registration procedures for configuration within
the Application Server. ASP Inactive and Deregister messages
exchanges may contain multiple Routing Contexts.
The ASP should be in the ASP-INACTIVE state and should have
deregistered in all its Routing Contexts before attempting to move to
the ASP-DOWN state.
5.4. Auditing Examples
5.4.1. SG State: Uncongested/Available
ASP SGP
--- ---
| -------- DAUD ---------> |
| <------ SCON(0) -------- |
| <------- DAVA ---------- |
5.4.2. SG State: Congested (Congestion Level=2) / Available
ASP SGP
--- ---
| -------- DAUD ---------> |
| <------ SCON(2) -------- |
| <------- DAVA ---------- |
5.4.3. SG State: Unknown/Available
ASP SGP
--- ---
| -------- DAUD ---------> |
| <------- DAVA ---------- |
Morneault & Pastor-Balbas Standards Track [Page 107]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
5.4.4. SG State: Unavailable
ASP SGP
--- ---
| -------- DAUD ---------> |
| <------- DUNA ---------- |
5.5. M3UA/MTP3-User Boundary Examples
5.5.1. At an ASP
This section describes the primitive mapping between the MTP3 User
and the M3UA layer at an ASP.
5.5.1.1. Support for MTP-TRANSFER Primitives at the ASP
5.5.1.1.1. Support for MTP-TRANSFER Request Primitive
When the MTP3-User on the ASP has data to send to a remote MTP3-User,
it uses the MTP-TRANSFER request primitive. The M3UA layer at the
ASP will do the following when it receives an MTP-TRANSFER request
primitive from the M3UA user:
- Determine the correct SGP.
- Determine the correct association to the chosen SGP.
- Determine the correct stream in the association (e.g.,
based on SLS).
- Determine whether to complete the optional fields of the DATA
message.
- Map the MTP-TRANSFER request primitive into the Protocol Data
field of a DATA message.
- Send the DATA message to the remote M3UA peer at the SGP,
over the SCTP association.
SGP ASP
| |
|<-----DATA Message-------|<--MTP-TRANSFER req.
| |
5.5.1.1.2. Support for the MTP-TRANSFER Indication Primitive
When the M3UA layer on the ASP receives a DATA message from the M3UA
peer at the remote SGP, it will do the following:
Morneault & Pastor-Balbas Standards Track [Page 108]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
- Evaluate the optional fields of the DATA message, if present.
- Map the Protocol Data field of a DATA message into the
MTP-TRANSFER indication primitive.
- Pass the MTP-TRANSFER indication primitive to the user part. In
case of multiple user parts, the optional fields of the Data
message are used to determine the concerned user part.
SGP ASP
| |
|------Data Message------>|-->MTP-Transfer ind.
| |
5.5.1.1.3. Support for ASP Querying of SS7 Destination States
There are situations such as temporary loss of connectivity to the
SGP that may cause the M3UA layer at the ASP to audit SS7 destination
availability/congestion states. Note: there is no primitive for the
MTP3-User to request this audit from the M3UA layer, as this is
initiated by an internal M3UA management function.
SGP ASP
| |
|<----------DAUD-----------|
|<----------DAUD-----------|
|<----------DAUD-----------|
| |
| |
5.5.2. At an SGP
This section describes the primitive mapping between the MTP3-User
and the M3UA layer at an SGP.
5.5.2.1. Support for MTP-TRANSFER Request Primitive at the SGP
When the M3UA layer at the SGP has received DATA messages from its
peer destined to the SS7 network, it will do the following:
- Evaluate the optional fields of the DATA message, if present, to
determine the Network Appearance.
- Map the Protocol data field of the DATA message into an
MTP-TRANSFER request primitive.
- Pass the MTP-TRANSFER request primitive to the MTP3 of the
concerned Network Appearance.
Morneault & Pastor-Balbas Standards Track [Page 109]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
SGP ASP
| |
<---MTP-TRANSFER req.|<---------DATA -----------|
| |
5.5.2.2. Support for MTP-TRANSFER Indication Primitive at the SGP
When the MTP3 layer at the SGP has data to pass its user parts, it
will use the MTP-TRANSFER indication primitive. The M3UA layer at
the SGP will do the following when it receives an MTP-TRANSFER
indication primitive:
- Determine the correct AS, using the distribution function;
- Select an ASP in the ASP-ACTIVE state.
- Determine the correct association to the chosen ASP.
- Determine the correct stream in the SCTP association (e.g.,
based on SLS).
- Determine whether to complete the optional fields of the DATA
message.
- Map the MTP-TRANSFER indication primitive into the Protocol Data
field of a DATA message.
- Send the DATA message to the remote M3UA peer in the ASP, over
the SCTP association.
SGP ASP
| |
--MTP-TRANSFER ind.->|-----------DATA --------->|
| |
5.5.2.3. Support for MTP-PAUSE, MTP-RESUME, MTP-STATUS Indication
Primitives
The MTP-PAUSE, MTP-RESUME, and MTP-STATUS indication primitives from
the MTP3 upper layer interface at the SGP need to be made available
to the remote MTP3 User Part lower-layer interface at the concerned
ASP(s).
5.5.2.3.1. Destination Unavailable
The MTP3 layer at the SGP will generate an MTP-PAUSE indication
primitive when it determines locally that an SS7 destination is
unreachable. The M3UA layer will map this primitive to a DUNA
Morneault & Pastor-Balbas Standards Track [Page 110]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
message. The SGP M3UA layer determines the set of concerned ASPs to
be informed based on internal SS7 network information associated with
the MTP-PAUSE indication primitive indication.
SGP ASP
| |
--MTP-PAUSE ind.-->|---------DUNA----------->|--MTP-PAUSE ind.-->
| |
5.5.2.3.2. Destination Available
The MTP3 at the SGP will generate an MTP-RESUME indication primitive
when it determines locally that an SS7 destination that was
previously unreachable is now reachable. The M3UA layer will map
this primitive to a DAVA message. The SGP M3UA determines the set of
concerned ASPs to be informed based on internal SS7 network
information associated with the MTP-RESUME indication primitive.
SGP ASP
| |
--MTP-RESUME ind.-->|-----------DAVA--------->|--MTP-RESUME ind.-->
| |
5.5.2.3.3. SS7 Network Congestion
The MTP3 layer at the SGP will generate an MTP-STATUS indication
primitive when it determines locally that the route to an SS7
destination is congested. The M3UA layer will map this primitive to
a SCON message. It will determine which ASP(s) to send the SCON
message to, based on the intended Application Server.
SGP ASP
| |
--MTP-STATUS ind.-->|-----------SCON--------->|--MTP-STATUS ind.-->
| |
5.5.2.3.4. Destination User Part Unavailable
The MTP3 layer at the SGP will generate an MTP-STATUS indication
primitive when it receives an UPU message from the SS7 network. The
M3UA layer will map this primitive to a DUPU message. It will
determine which ASP(s) to send the DUPU to based on the intended
Application Server.
SGP ASP
| |
--MTP-STATUS ind.-->|----------DUPU---------->|--MTP-STATUS ind.-->
| |
Morneault & Pastor-Balbas Standards Track [Page 111]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
5.6. Examples for IPSP Communication
These scenarios show a basic example for IPSP communication for the
three phases of the connection (establishment, data exchange,
disconnection). It is assumed that the SCTP association is already
set up. Both single exchange and double exchange behavior are
included for illustrative purposes.
5.6.1. Single Exchange
IPSP-A IPSP-B
| |
|-------------ASP Up------------>|
|<----------ASP Up Ack-----------|
| |
|<------- ASP Active(RCb)--------| RC: Routing Context
|-----ASP Active Ack (RCb)------>| (optional)
| |
| |
|<========= DATA (RCb) ========>|
| |
|<-----ASP Inactive (RCb)--------| RC: Routing Context
|----ASP Inactive Ack (RCb)----->| (optional)
| |
|<-----------ASP Down------------|
|---------ASP Down Ack---------->|
| |
Routing Context is previously agreed to be the same in both
directions.
Morneault & Pastor-Balbas Standards Track [Page 112]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
5.6.2. Double Exchange
IPSP-A IPSP-B
| |
|<-------------ASP Up------------|
|-----------ASP Up Ack---------->|
| |
|-------------ASP Up------------>| (optional)
|<----------ASP Up Ack-----------| (optional)
| |
|<------- ASP Active(RCb)--------| RC: Routing Context
|-----ASP Active Ack (RCb)------>| (optional)
| |
|------- ASP Active(RCa)-------->| RC: Routing Context
|<-----ASP Active Ack (RCa)------| (optional)
| |
|<========= DATA (RCa) =========|
|========== DATA (RCb) ========>|
| |
|<-----ASP Inactive (RCb)--------| RC: Routing Context
|----ASP Inactive Ack (RCb)----->|
| |
|------ASP Inactive (RCa)------->| RC: Routing Context
|<----ASP Inactive Ack (RCa)-----|
| |
|<-----------ASP Down------------|
|---------ASP Down Ack---------->|
| |
|------------ASP Down----------->| (optional)
|<--------ASP Down Ack-----------| (optional)
| |
In this approach, only one single exchange of ASP Up message can be
considered sufficient since the response by the other peer can be
considered a notice that it is in ASP_UP state.
For the same reason, only one ASP Down message is needed, since once
an IPSP receives ASP_Down ack message it is itself considered to be
in the ASP_Down state and not allowed to receive ASPSM messages.
6. Security Considerations
Implementations MUST follow the normative guidance of RFC3788 [11] on
the integration and usage of security mechanisms in SIGTRAN
protocols.
Morneault & Pastor-Balbas Standards Track [Page 113]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
7. IANA Considerations
This document contains no new actions for IANA. The subsections
below are retained for historical purposes.
7.1. SCTP Payload Protocol Identifier
IANA has assigned an M3UA value for the Payload Protocol Identifier
in the SCTP DATA chunk. The following SCTP Payload Protocol
Identifier has been registered:
M3UA "3"
The SCTP Payload Protocol Identifier value "3" SHOULD be included in
each SCTP DATA chunk, to indicate that the SCTP is carrying the M3UA
protocol. The value "0" (unspecified) is also allowed but any other
values MUST not be used. This Payload Protocol Identifier is not
directly used by SCTP but MAY be used by certain network entities to
identify the type of information being carried in a DATA chunk.
The User Adaptation peer MAY use the Payload Protocol Identifier as a
way of determining additional information about the data being
presented to it by SCTP.
7.2. M3UA Port Number
IANA has registered SCTP (and UDP/TCP) Port Number 2905 for M3UA. It
is recommended that SGPs use this SCTP port number for listening for
new connections. SGPs MAY also use statically configured SCTP port
numbers instead.
7.3. M3UA Protocol Extensions
This protocol may also be extended through IANA in three ways:
- Through definition of additional message classes.
- Through definition of additional message types.
- Through definition of additional message parameters.
The definition and use of new message classes, types, and parameters
is an integral part of SIGTRAN adaptation layers. Thus, these
extensions are assigned by IANA through an IETF Consensus action as
defined in Guidelines for Writing an IANA Considerations Section in
RFCs [23].
The proposed extension must in no way adversely affect the general
working of the protocol.
Morneault & Pastor-Balbas Standards Track [Page 114]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
7.3.1. IETF-Defined Message Classes
The documentation for a new message class MUST include the following
information:
(a) A long and short name for the new message class.
(b) A detailed description of the purpose of the message class.
7.3.2. IETF Defined Message Types
The documentation for a new message type MUST include the following
information:
(a) A long and short name for the new message type.
(b) A detailed description of the structure of the message.
(c) A detailed definition and description of intended use for each
field within the message.
(d) A detailed procedural description of the use of the new
message type within the operation of the protocol.
(e) A detailed description of error conditions when receiving this
message type.
When an implementation receives a message type that it does not
support, it MUST respond with an Error (ERR) message ("Unsupported
Message Type").
7.3.3. IETF-Defined Parameter Extension
Documentation of the message parameter MUST contain the following
information:
(a) Name of the parameter type.
(b) Detailed description of the structure of the parameter field.
This structure MUST conform to the general type-length-value
format described in Section 3.2.
(c) Detailed definition of each component of the parameter value.
(d) Detailed description of the intended use of this parameter
type, and an indication of whether and under what
circumstances multiple instances of this parameter type may be
found within the same message.
8. Acknowledgements
The authors would like to thank Antonio Roque Alvarez, Joyce
Archibald, Tolga Asveren, Maria-Cruz Bartolome-Rodrigo, Dan Brendes,
Antonio Canete, Nikhil Jain, Roland Jesske, Joe Keller, Kurt Kite,
Ming Lin, Steve Lorusso, Naoto Makinae, Howard May, Francois
Mouillaud, Barry Nagelberg, Neil Olson, Heinz Prantner, Shyamal
Morneault & Pastor-Balbas Standards Track [Page 115]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
Prasad, Mukesh Punhani, Selvam Rengasami, John Schantz, Ray Singh,
Michael Tuexen, Nitin Tomar, Gery Verwimp, Tim Vetter, Kazuo
Watanabe, Ben Wilson, and many others for their valuable comments and
suggestions.
9. Document Contributors
Ian Rytina - Ericsson
Guy Mousseau - Nortel Networks
Lyndon Ong - Ciena
Hanns Juergen Schwarzbauer - Siemens
Klaus Gradischnig - Detecon Inc.
Mallesh Kalla - Telcordia
Normand Glaude - Performance Technologies
Brian Bidulock - OpenSS7
John Loughney - Nokia
Greg Sidebottom - Signatus Technologies
10. References
10.1. Normative References
[1] ITU-T Recommendations Q.761 to Q.767, "Signalling System No.7
(SS7) - ISDN User Part (ISUP)"
[2] ANSI T1.113 - "Signaling System Number 7 - ISDN User Part"
[3] ETSI ETS 300 356-1 "Integrated Services Digital Network (ISDN);
Signalling System No.7; ISDN User Part (ISUP) version 2 for the
international interface; Part 1: Basic services"
[4] ITU-T Recommendations Q.711 to Q.715, "Signalling System No. 7
(SS7) - Signalling Connection Control Part (SCCP)"
[5] ANSI T1.112 "Signaling System Number 7 - Signaling Connection
Control Part"
[6] ETSI ETS 300 009-1, "Integrated Services Digital Network (ISDN);
Signalling System No.7; Signalling Connection Control Part
(SCCP) (connectionless and connection-oriented class 2) to
support international interconnection; Part 1: Protocol
specification"
[7] ITU-T Recommendations Q.700 to Q.705, "Signalling System No. 7
(SS7) - Message Transfer Part (MTP)"
[8] ANSI T1.111 "Signaling System Number 7 - Message Transfer Part"
Morneault & Pastor-Balbas Standards Track [Page 116]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
[9] ETSI ETS 300 008-1, "Integrated Services Digital Network (ISDN);
Signalling System No.7; Message Transfer Part (MTP) to support
international interconnection; Part 1: Protocol specification"
[10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
63, RFC 3629, November 2003.
[11] Loughney, J., Tuexen, M., and J. Pastor-Balbas, "Security
Considerations for Signaling Transport (SIGTRAN) Protocols", RFC
3788, June 2004.
10.2. Informative References
[12] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L.,
Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Framework
Architecture for Signaling Transport", RFC 2719, October 1999.
[13] ITU-T Recommendation Q.720, "Telephone User Part"
[14] ITU-T Recommendations Q.771 to Q.775 "Signalling System No. 7
(SS7) - Transaction Capabilities (TCAP)"
[15] ANSI T1.114 "Signaling System Number 7 - Transaction
Capabilities Application Part"
[16] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN);
Signalling System No.7; Transaction Capabilities (TC) version 2;
Part 1: Protocol specification"
[17] 3G TS 25.410 V4.0.0 (2001-04) "Technical Specification - 3rd
Generation partnership Project; Technical Specification Group
Radio Access Network; UTRAN Iu Interface: General Aspects and
Principles"
[18] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[19] ITU-T Recommendation Q.2140 "B-ISDN ATM Adaptation Layer -
Service Specific Coordination Function for signalling at the
Network Node Interface (SSCF at NNI)"
[20] ITU-T Recommendation Q.2110 "B-ISDN ATM Adaptation Layer -
Service Specific Connection Oriented Protocol (SSCOP)"
[21] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Morneault & Pastor-Balbas Standards Track [Page 117]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
[22] ITU-T Recommendation Q.2210 "Message Transfer Part Level 3
functions and messages using the services of ITU Recommendation
Q.2140"
[23] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[24] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B., and J.
Heitz, "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2)
- User Adaptation Layer", RFC 3331, September 2002.
[25] George, T., Bidulock, B., Dantu, R., Schwarzbauer, H., and K.
Morneault, "Signaling System 7 (SS7) Message Transfer Part 2
(MTP2) - User Peer-to-Peer Adaptation Layer (M2PA)", RFC 4165,
September 2005.
[26] Telecommunication Technology Committee (TTC) Standard JT-Q704,
"Message Transfer Part Signaling Network Functions", April 28,
1992.
Morneault & Pastor-Balbas Standards Track [Page 118]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
Appendix A
A.1. Signalling Network Architecture
A Signalling Gateway is used to support the transport of MTP3-User
signalling traffic received from the SS7 network to multiple
distributed ASPs (e.g., MGCs and IP Databases). Clearly, the M3UA
protocol is not designed to meet the performance and reliability
requirements for such transport by itself. However, the conjunction
of distributed architecture and redundant networks provides support
for reliable transport of signalling traffic over IP. The M3UA
protocol is flexible enough to allow its operation and management in
a variety of physical configurations, enabling Network Operators to
meet their performance and reliability requirements.
To meet the stringent SS7 signalling reliability and performance
requirements for carrier grade networks, Network Operators might
require that no single point of failure is present in the end-to-end
network architecture between an SS7 node and an IP-based application.
This can typically be achieved through the use of redundant SGPs or
SGs, redundant hosts, and the provision of redundant QOS-bounded IP
network paths for SCTP Associations between SCTP End Points.
Obviously, the reliability of the SG, the MGC, and other IP-based
functional elements also needs to be taken into account. The
distribution of ASPs and SGPs within the available Hosts MAY also be
considered. As an example, for a particular Application Server, the
related ASPs could be distributed over at least two Hosts.
One example of a physical network architecture relevant to SS7
carrier grade operation in the IP network domain is shown in Figure
A-1, below:
Morneault & Pastor-Balbas Standards Track [Page 119]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
SGs MGCs
Host#1 ************** ************** Host#3
* ********__*__________________________*__******** * =
* *SGP1.1*__*_____ _______________*__* ASP1 * * MGC1
* ******** * \ / * ******** *
* ********__*______\__/________________*__******** *
* *SGP2.1*__*_______\/______ _____*__* ASP2 * *
* ******** * /\ | | * ******** *
* : * / \ | | * : *
* ******** * / \ | | * ******** *
* * SGPn * * | | | | * * ASPn * *
* ******** * | | | | * ******** *
************** | | | | **************
| | \ /
Host#2 ************** | | \ / ************** Host#4
* ********__*_____| |______\/_______*__******** * =
* *SGP1.2*__*_________________/\_______*__* ASP1 * * MGC2
* ******** * / \ * ******** *
* ********__*_______________/ \_____*__******** *
* *SGP2.2*__*__________________________*__* ASP2 * *
* ******** * * ******** *
* : * SCTP Associations * : *
* ******** * * ******** *
* * SGPn * * * * ASPn * *
* ******** * * ******** *
************** **************
SGP1.1 and SGP1.2 are part of SG1
SGP2.1 and SGP2.2 are part of SG2
Figure A-1 - Physical Model
In this model, each host may have many application processes. In the
case of the MGC, an ASP may provide service to one or more
Application Servers, and is identified as an SCTP end point. One or
more Signalling Gateway Processes make up a single Signalling
Gateway.
This example model can also be applied to IPSP-IPSP signalling. In
this case, each IPSP may have its services distributed across 2 or
more hosts, and may have multiple server processes on each host.
In the example above, each signalling process (SGP, ASP, or IPSP) is
the end point to more than one SCTP association, leading to more than
one other signalling processes. To support this, a signalling
process must be able to support distribution of M3UA messages to many
simultaneous active associations. This message distribution function
Morneault & Pastor-Balbas Standards Track [Page 120]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
is based on the status of provisioned Routing Keys, the status of the
signalling routes to signalling points in the SS7 network, and the
redundancy model (active-standby, load sharing, broadcast, n+k) of
the remote signalling processes.
For carrier grade networks, the failure or isolation of a particular
signalling process should not cause stable calls or transactions to
be lost. This implies that signalling processes need, in some cases,
to share the call/transaction state or be able to pass the call state
information between each other. In the case of ASPs performing call
processing, coordination may also be required with the related Media
Gateway to transfer the MGC control for a particular trunk
termination. However, this sharing or communication of
call/transaction state information is outside the scope of this
document.
This model serves as an example. M3UA imposes no restrictions as to
the exact layout of the network elements, the message distribution
algorithms, and the distribution of the signalling processes.
Instead, it provides a framework and a set of messages that allow for
a flexible and scalable signalling network architecture, aiming to
provide reliability and performance.
A.2. Redundancy Models
A.2.1. Application Server Redundancy
At the SGP, an Application Server list contains active and inactive
ASPs to support ASP broadcast, loadsharing, and failover procedures.
The list of ASPs within a logical Application Server is kept updated
in the SGP to reflect the active Application Server Process(es).
For example, in the network shown in Figure 1, all messages to DPC x
could be sent to ASP1 in Host3 or ASP1 in Host4. The AS list at SGP1
in Host 1 might look like the following:
Routing Key {DPC=x) - "Application Server #1"
ASP1/Host3 - State = Active
ASP1/Host4 - State = Inactive
In this "1+1" redundancy case, ASP1 in Host3 would be sent any
incoming message with DPC=x. ASP1 in Host4 would normally be brought
to the "active" state upon failure of, or loss of connectivity to,
ASP1/Host1.
The AS List at SGP1 in Host1 might also be set up in loadshare mode:
Morneault & Pastor-Balbas Standards Track [Page 121]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
Routing Key {DPC=x) - "Application Server #1"
ASP1/Host3 - State = Active
ASP1/Host4 - State = Active
In this case, both the ASPs would be sent a portion of the traffic.
For example, the two ASPs could together form a database, where
incoming queries may be sent to any active ASP.
Care might need to be exercised by a Network Operator in the
selection of the routing information to be used as the Routing Key
for a particular AS.
In the process of failover, it is recommended that, in the case of
ASPs supporting call processing, stable calls do not fail. It is
possible that calls in "transition" may fail, although measures of
communication between the ASPs involved can be used to mitigate this.
For example, the two ASPs may share call state via shared memory, or
may use an ASP to ASP protocol to pass call state information. Any
ASP-to-ASP protocol to support this function is outside the scope of
this document.
A.2.2. Signalling Gateway Redundancy
Signalling Gateways may also be distributed over multiple hosts.
Much like the AS model, SGs may comprise one or more SG Processes
(SGPs), distributed over one or more hosts, using an active/backup or
a loadsharing model. Should an SGP lose all or partial SS7
connectivity and other SGPs exist, the SGP may terminate the SCTP
associations to the concerned ASPs.
It is therefore possible for an ASP to route signalling messages
destined to the SS7 network using more than one SGP. In this model,
a Signalling Gateway is deployed as a cluster of hosts acting as a
single SG. A primary/backup redundancy model is possible, where the
unavailability of the SCTP association to a primary SGP could be used
to reroute affected traffic to an alternate SGP. A loadsharing model
is possible, where the signalling messages are loadshared between
multiple SGPs. A broadcast model is also possible, where signalling
messages are sent to each active SGP in the SG. The distribution of
the MTP3-user messages over the SGPs should be done in such a way to
minimize message missequencing, as required by the SS7 User Parts.
It may also be possible for an ASP to use more than one SG to access
a specific SS7 end point, in a model that resembles an SS7 STP mated
pair. Typically, SS7 STPs are deployed in mated pairs, with traffic
loadshared between them. Other models are also possible, subject to
the limitations of the local SS7 network provisioning guidelines.
Morneault & Pastor-Balbas Standards Track [Page 122]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
From the perspective of the M3UA layer at an ASP, a particular SG is
capable of transferring traffic to a provisioned SS7 destination X if
an SCTP association with at least one SGP of the SG is established,
the SGP has returned an acknowledgement to the ASP to indicate that
the ASP is actively handling traffic for that destination X, the SGP
has not indicated that the destination X is inaccessible, and the SGP
has not indicated MTP Restart. When an ASP is configured to use
multiple SGPs for transferring traffic to the SS7 network, the ASP
must maintain knowledge of the current capability of the SGPs to
handle traffic to destinations of interest. This information is
crucial to the overall reliability of the service, for active/backup,
loadsharing, and broadcast models, in the event of failures and
recovery and maintenance activities. The ASP M3UA may also use this
information for congestion avoidance purposes. The distribution of
the MTP3-user messages over the SGPs should be done in such a way as
to minimize message missequencing, as required by the SS7 User Parts.
Editors' Addresses
Ken Morneault
Cisco Systems Inc.
13615 Dulles Technology Drive
Herndon, VA, USA 20171
EMail: kmorneau@cisco.com
Javier Pastor-Balbas
Ericsson Espana S.A.
C/ Retama 1
28045 Madrid - Spain
EMail: j.javier.pastor@ericsson.com
Morneault & Pastor-Balbas Standards Track [Page 123]
RFC 4666 SS7 MTP3-User Adaptation Layer September 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Morneault & Pastor-Balbas Standards Track [Page 124]