From santhana@huawei.com Tue Aug 2 02:38:43 2011 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C857921F8F04 for ; Tue, 2 Aug 2011 02:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJoj8AKHuUkx for ; Tue, 2 Aug 2011 02:38:43 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id B4E9921F8ED0 for ; Tue, 2 Aug 2011 02:38:42 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPA0000KO2GYS@szxga03-in.huawei.com> for sigtran@ietf.org; Tue, 02 Aug 2011 17:37:28 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPA0069YO2GQP@szxga03-in.huawei.com> for sigtran@ietf.org; Tue, 02 Aug 2011 17:37:28 +0800 (CST) Received: from BLRNSHTIPL2NC ([10.18.1.32]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LPA00BMHO2F28@szxml06-in.huawei.com> for sigtran@ietf.org; Tue, 02 Aug 2011 17:37:28 +0800 (CST) Date: Tue, 02 Aug 2011 14:49:47 +0530 From: Santhana To: sigtran@ietf.org Message-id: <22F63C65FA1E4B719CB13EBFEF17D8D0@china.huawei.com> Organization: Htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4862 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_5o6Hu0nVxtmPxGRp8MNKGA)" Thread-index: AcxQ9VJ7iPrZZivSSTSw8SNPH/rDEQ== Subject: [Sigtran] [M3UA] NA validation X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: santhana@huawei.com List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 09:38:43 -0000 This is a multi-part message in MIME format. --Boundary_(ID_5o6Hu0nVxtmPxGRp8MNKGA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi When the Network Appearance, is found invalid the RFC suggests that the SGP should send an ERROR(INVALID_NETWORK_APPEARANCE) message. Based on this, it leads to some confusion 1) Can SGP also include NA in messages sent to ASP. Or only the ASP should include NA in the messages sent to SGP ? 2) If the ASP finds invalid NA, can it also send the above ERROR(INVALID_ NETWORK_APPEARANCE) message ? Also when Network Appearance is invalid, what should be the treatment for the offending message. Should it be discarded or can it be processed(if an implementation can process it without NA) ? Pls clarify. regards Santhana --Boundary_(ID_5o6Hu0nVxtmPxGRp8MNKGA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi

            When the Network Appearance, is found invalid the RFC suggests that the SGP should send an ERROR(INVALID_NETWORK_APPEARANCE) message.

 

Based on this, it leads to some confusion

1)       Can SGP also include NA in messages sent to ASP. Or only the ASP should include NA in the messages sent to SGP ?

2)       If the ASP finds invalid NA, can it also send the above ERROR(INVALID_ NETWORK_APPEARANCE) message ?

 

Also when Network Appearance is invalid, what should be the treatment for the offending message. Should it be discarded or can it be processed(if an implementation can process it without NA) ?

 

Pls clarify.

 

regards

Santhana

--Boundary_(ID_5o6Hu0nVxtmPxGRp8MNKGA)-- From bidulock@openss7.org Tue Aug 2 16:43:47 2011 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EB811E80DD for ; Tue, 2 Aug 2011 16:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9ksclWmH41S for ; Tue, 2 Aug 2011 16:43:46 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.117.178]) by ietfa.amsl.com (Postfix) with ESMTP id 9746711E8095 for ; Tue, 2 Aug 2011 16:43:46 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p72Nhmdm001521; Tue, 2 Aug 2011 17:43:48 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p72NhlcN013615; Tue, 2 Aug 2011 17:43:47 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p72NhlXV013611; Tue, 2 Aug 2011 17:43:47 -0600 Date: Tue, 2 Aug 2011 17:43:47 -0600 From: "Brian F. G. Bidulock" To: Santhana Message-ID: <20110802234347.GA3338@openss7.org> Mail-Followup-To: Santhana , sigtran@ietf.org References: <22F63C65FA1E4B719CB13EBFEF17D8D0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22F63C65FA1E4B719CB13EBFEF17D8D0@china.huawei.com> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sigtran@ietf.org Subject: Re: [Sigtran] [M3UA] NA validation X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 23:43:47 -0000 Santhana, Santhana wrote: (Tue, 02 Aug 2011 14:49:47) > Hi > > When the Network Appearance, is found invalid the RFC > suggests that the SGP should send an ERROR(INVALID_NETWORK_APPEARANCE) > message. > > > Based on this, it leads to some confusion > > 1) Can SGP also include NA in messages sent to ASP. Or only the > ASP should include NA in the messages sent to SGP ? Read RFC 4666/3.3.1. > 2) If the ASP finds invalid NA, can it also send the above > ERROR(INVALID_ NETWORK_APPEARANCE) message ? Why not? > Also when Network Appearance is invalid, what should be the treatment > for the offending message. Should it be discarded or can it be > processed(if an implementation can process it without NA) ? Your choice. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From aditi.someshwar@gmail.com Mon Aug 8 01:17:20 2011 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EFA21F86A9 for ; Mon, 8 Aug 2011 01:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-+W1+SQL1ro for ; Mon, 8 Aug 2011 01:17:19 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 41DED21F855F for ; Mon, 8 Aug 2011 01:17:19 -0700 (PDT) Received: by iye1 with SMTP id 1so8252252iye.27 for ; Mon, 08 Aug 2011 01:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=kgxsP8s9MK9SUFF7hFtweJpasE+0FVywmFPmSLQfHWE=; b=PXuS/6SseJ4zowjXgqDheNostCSPUnRJ5o9kYR4TUMY7NQQqvxF0ZQ8OGhfWU7ajjz IrScrnJtxdVvcZKQn2ab9kpJyvR03SCih8HvLUqCBPWWSEwitIF1ZcGq86d4SQUZ6zQV Ueti/+XBqoNLt/SB2imPlfWYGaB1yC7a9lq8c= MIME-Version: 1.0 Received: by 10.231.115.36 with SMTP id g36mr5041657ibq.3.1312791463213; Mon, 08 Aug 2011 01:17:43 -0700 (PDT) Received: by 10.231.54.7 with HTTP; Mon, 8 Aug 2011 01:17:42 -0700 (PDT) Date: Mon, 8 Aug 2011 13:47:42 +0530 Message-ID: From: aditi someshwar To: sigtran@ietf.org Content-Type: multipart/alternative; boundary=00163628509cd4398c04a9fa1406 Subject: [Sigtran] M3UA - Clarification on RFC 1.3.2.1 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 08:17:20 -0000 --00163628509cd4398c04a9fa1406 Content-Type: text/plain; charset=ISO-8859-1 *RFC4666* 1.3.2.1. Support for the Transport of MTP3-User Messages Fact (Quote): The M3UA layer provides the transport of MTP-TRANSFER primitives across an established SCTP association between an SGP and an ASP or between IPSPs. QUERY: The RFC seems to suggest that "MTP-TRANSFER PRIMITIVE itself" is transported between NODE-A & NODE-B; our belief is that the "CONSEQUENCE(result)" of having acted upon a primitive is what is transported - - meaning that the PAYLOAD passed over by the "MTP-3 User" under the primitive "MTP-TRANSFER" is what gets transported. COMMENT: In a LOGICAL sense, OF COURSE, it would mean that when AT THE SENDING NODE, the "MTP-3 User" passes down a PAYLOAD to its LOCAL M3UA (requesting for its TRANSPORT to the remote nodeB), the M3UA does ACTION this, & with help from SCTP, causes this PAYLOAD to be transported across. At the receiving node, the M3UA shall get the PAYLOAD from its local SCTP, which it will in-turn handover to the UL {"MTP-3 User at node B"}. TO THAT EXTENT, use of the phrase "transports MTP- TRANSFER PRIMITIVE" is perhaps understandable, BUT the fact remains that it is confusing!!! Any Comments please??? Regards, Aditi --00163628509cd4398c04a9fa1406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
RFC= 4666

1.3.2.1. =A0Support for the Transport of MTP3-User = Messages

Fact (Quote): The M3UA layer provides the tr= ansport of MTP-TRANSFER primitives=A0across an established SCTP as= sociation between an SGP and an ASP or=A0between IPSPs.

Q= UERY: The RFC seems to suggest that "MTP-TRANSFER PRIMITIVE itself&quo= t; is transported between NODE-A & NODE-B; our belief is that the "= ;CONSEQUENCE(result)" of having acted upon a primitive is what is tran= sported - - meaning that the PAYLOAD passed over by the=A0"= MTP-3 User" under the primitive "MTP-TRANSFER" is what gets = transported.

COMMENT: In a LOGICAL sense, OF COURSE, it w= ould mean that when AT THE SENDING NODE, the "MTP-3 =A0 =A0User" = passes down a PAYLOAD to its LOCAL M3UA (requesting for its TRANSPORT to th= e remote nodeB), =A0 =A0 the M3UA does ACTION this, & with help from SC= TP, causes this PAYLOAD to be transported across. At =A0 =A0the receiving n= ode, the M3UA shall get the PAYLOAD from its local SCTP, which it will in-t= urn =A0 =A0handover to the UL {"MTP-3 User at node B"}. TO THAT E= XTENT, use of the phrase "transports MTP- =A0 TRANSFER PRIMITIVE"= is perhaps understandable, BUT the fact remains that it is confusing!!!
=A0
Any Comments please???

Regards,=
Aditi
--00163628509cd4398c04a9fa1406-- From aditi.someshwar@gmail.com Mon Aug 8 02:04:07 2011 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204B921F8AAC for ; Mon, 8 Aug 2011 02:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNK3S8kAzCC8 for ; Mon, 8 Aug 2011 02:04:05 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9458021F8A96 for ; Mon, 8 Aug 2011 02:04:05 -0700 (PDT) Received: by iye1 with SMTP id 1so8323320iye.27 for ; Mon, 08 Aug 2011 02:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=8Fd8OkIMyK8SuBzug4k3UiMWzjMexA92lCMfB8sF2rI=; b=hZDf2iHS18Xl1G+khb3UdtmPa0FeUpuS8t64aYm+Q5tcU+aTUIY8wcUUNYPXJptsN1 9Y8LBsFVezPAL2sd32zyKMOa6hCugJhspVo9o/ZIf3KQfMBvBYz+6AQ8TL+acyE4I0Pk ff2L68aLedvFqwFd+Ay/7lqT2X1i4n1nn/WNc= MIME-Version: 1.0 Received: by 10.231.3.129 with SMTP id 1mr5123333ibn.42.1312794270748; Mon, 08 Aug 2011 02:04:30 -0700 (PDT) Received: by 10.231.54.7 with HTTP; Mon, 8 Aug 2011 02:04:30 -0700 (PDT) Date: Mon, 8 Aug 2011 14:34:30 +0530 Message-ID: From: aditi someshwar To: sigtran@ietf.org Content-Type: multipart/alternative; boundary=002215048a632bd21e04a9fabce9 Subject: [Sigtran] SIGTRAN specs: Some doubts X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 09:04:07 -0000 --002215048a632bd21e04a9fabce9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, We are a "Telecom Training Group" based out of India. Listed below, are few doubts from our study of the SIGTRAN RFC documents. We would be grateful if you can contribute with the clarifications. The list of queries is long, and we have segregated the points as per the SIGTRAN topics.. you may like to address any point that you are clear about= . *SCTP:* * * SCTP 1) We have understood that there are three mechanisms of RE-TRANSMISSION =96 (i) One governed by TIMER that is started each time any message is sent (within this timer, an ACK must arrive for the UDM); (ii) If for a given message, an indication is received FOUR TIMES CONSECUTIVELY in the SACK that "so & so" message is a missing sequenc= e case; (iii) under CHANGEOVER. Is that correct, OR are (iii) there any more conditions that we have missed? Having concluded that RE-TRANSMISSION has to be done, is there a MANDATE that suc= h RE-TRANSMISSIONs must be done using SECONDARY PATH (for the same association) even when the PRIMARY PATH is healthy? Are "Primary Path" and "Secondary Path" pre-nominated (defined by human being at the time of configuration) OR are they dynamically changed depending on which path is u= p at any given point in time, & which one came up later etc? *User Adaptation (General):* * * UA 1) What is the exact meaning of "proper management" of streams in UA layer? For example: RFC 4165: It is the responsibility of the M2PA layer to ensure proper management of the streams allowed within each association. Another example of this is in 1.5.4.1 of RFC 3331 (M2UA) which states: "SCTP allows a user specified number of streams to be opened during initialization of th= e association. It is the responsibility of the M2UA layer to ensure proper management of these streams. Because of the unidirectional nature of streams, a M2UA layer is not aware of the stream information from its peer M2UA layer (our query is WHY SHOULD IT BE AWARE??). For this reason, the Interface Identifier is in the M2UA message header"; perhaps, the NEED for communicating the INTERFACE ID from one M2UA to its PEER also arises from this "responsibility" that M2UA (or any adaptation layer - for that matter) must PROPERLY MANAGE the Streams - - is that correct?? If so, the question of "what is 'proper management' becomes more crucial!! UA 2) Definition of "IPSP" in RFC4666 (M3UA) & RFC 3868 SUA refers to IP Server Process where as in RFC4165 (M2PA) refers to IP Signalling Point. Is it an error that same accronym has been used in different RFCs to represent entities or is there a point that we are missing? Moreover in RFC3331 (M2UA) it is completely absent - it keeps refering to MGC; can we not say that MGC is also an IPSP (to us IPSP appears to be a more generic term than MGC, Is it correct?).It is understandable that IPSP as a term is missing as a term for SCTP. UA 3) We find that definition of SG in various RFCs is broadly similar with minor variations (e.g. M3UA states that SG has a Point Code, while M2UA doe= s not naturally have any reference to Point Code). We are a bit concerned and confused as to why IETF has chosen to make definitions RFC specific. *M2PA:* * * M2PA 1) RFC 4165: 4.1.2 Figure 10. Multiple Associations Between Two IP Addresses are there any guidelines for choosing "pre-selected port number"? (P1) M2PA 2) RFC 4165: 4.1.4 Processor Outage M2PA (at both the LPO and RPO ends) uses the BSN value in the received Link Status Ready message to resynchronize its sequence numbers, if this is required by MTP2. M2PA SHALL NOT resume transmitting User Data messages until it has sent the Link Status Ready message. Why does it mention MTP2? M2PA 3) RFC 4165: 4.1.5: Flow Control When the peer M2PA receives the first Link Status Busy message, it SHALL start the Remote Congestion timer T6 if there are messages in the retransmission buffer awaiting acknowledgement (i.e., T7 is running). M2PA SHALL stop the T7 timer if it is running. Additional Link Status Busy messages received while T6 is running do not cause T6 to be reset and do no= t cause T7 to be started. While T6 is running, T7 SHALL NOT be started. When the peer M2PA receives the Link Status Busy Ended message and T6 has not expired, it SHALL stop T6 (if T6 is running) and start T7 (if there are messages awaiting acknowledgement in the retransmission buffer). M2PA 4) Do you recall in RFC 4165 (or any other RFC) a reference to SSN being used as a parameter for "Changeover" with most significant 8 bits being set to zero? Is there a relation between FSN / BSN of M2PA and TSN / SSN of SCTP? *M2UA:* M2UA 1) While using M2UA, is there a restriction that on SS7 side of an SG, there can be only "one type" of node (say, PSTN Classical Switch) and on IP side of THAT SG, there can be only "one type" of node (say, MGC)? In one of tutorials (ZYTRAX), we have come across an expression that says: "The whole IP network is represented by a single point code that addresses the MGC at the network edge. Therefore all messages from the SS7 side going to the IP side are sent to the MGC through the SG. Do you agree with this statement? If yes, is that UNCONDITIONAL or this statement is true only under certain environment (like M2UA)?? Is ZYTRAX, for example, making this statement onl= y for a certain scenario - where M2UA is deployed for connecting up (say) PST= N SS7 node with MGC? * * M2UA 2) While using M2UA, is there a restriction that on SS7 side of an SG, there can be only "one type" of node (say, PSTN Classical Switch) and on IP side of THAT SG, there can be only "one type" of M2UA 3) In the RFC, it is stated that the M2UA SPECIFIC HEADER is present I= F AT ALL only for MAUP Message Class; however, it goes on to say that it may or may NOT be present in even when the message is an MAUP (MTP-2 User Adaptation Messages / Protocol??) messages. Thus, after Common Header, DIRECTLY, parameters may follow in T-L-V format. (i) Is it prescribed as to WHEN this can be (should be) absent, & when not - - e.g. does Message Type automatically give any clue for this?? (ii) How does the RECEIVING ENTITY come to know whether the M2UA specific header is present or not - - -is it by looking at the TWO BYTES that follow "end of COMMON HEADER (message length)", & if the value therein is "01 (Hex) - indicating Integar Value for IId", THEN CONCLUDE tha= t the (M2UA specific) header is present & IF IT IS ANYTHING OTHER THAN 01H (or, of course, 03H for ANSI Networks), then TRY TO INTERPRET the same as a "Parameter Tag"?? M2UA 3) In one of the (SS7 =96 with INTRO to SIGTRAN) training sessions tha= t we held last month, one of the trainees informed us that they have =93deployed=94 M2UA in the sense that they have a CLUSTER OF BLADE SERVERS = in their MGC. All those blades are represented by a SINGLE SIGNALLING POINT CODE, but EACH has a unique GT. The M2UA is used INTERNALLY between the SS7 front end (the =93master server=94- so to say), & the =93back-end=94 cluste= r of Blade Servers. Is this a typical usage that you have seen too (we ask this because it is usually very rare to SEE / get an example of, an M2UA deployment !!)? *M3UA:* * * M3UA 1) Section 1.1, Terminologies, states =93Where an SG contains more tha= n one SGP, the SG is a logical entity, and the contained SGPs are assumed to = *be coordinated into a single management view* to the SS7 network and to the supported Application Servers=94. We are confused about what the underline= d part means. M3UA 2) RFC also states that =93An IPSP is essentially the same as an ASP, except that it uses M3UA in a *point-to-point fashion*.=94 What does =93point-to-point=94 mean? M3UA 3) Routing Context is a 4 =96 byte number having a one-to-one relationship with Routing Key. Moreover, Routing context is also transmitte= d from 1 node to the other as part of the message. Is it correct to interpret that Routing Context is something similar to =93Translation Type=94 use in = SCCP =96 meaning possibly that the receiving node indexes a =93 (specific / desi= red) table=94 basis the received RC value, & LOOKS for Routing Key within that table? Thanks and Regards, Aditi --002215048a632bd21e04a9fabce9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi,
We ar= e a "Telecom Training Group" based out of India. Listed below, ar= e few doubts from our study of the SIGTRAN RFC documents. We would be grate= ful if you can contribute with the clarifications.
The list = of queries is long, and we have segregated the points as per the SIGTRAN to= pics.. you may like to address any point that you are clear about.

<= p class=3D"MsoNormal">SCTP:

=A0

SCTP 1) We have understood that there are three mech= anisms of RE-TRANSMISSION =96

(i)=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 One governed by TIMER that is started each time any message is sent (within this timer, an ACK must arrive for the UDM);

(ii)<= span style=3D"font:7.0pt "Times New Roman"">=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 If for a given message, an indication is received FOUR TIMES CONSECUTIVELY in the SACK that "so & so" message is a missing sequence case; (iii) under CHANGEOVER. Is that correct= , OR are

(iii)= =A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 there any more conditions that we have missed? Having concluded=A0 that RE-TRANSMISSION has to be done, is there a MANDATE that such RE-TRANSMISSIONs must be done using SECONDARY PATH (for the same association) even when the PRIMARY PATH is healthy? Are "Primary Path" and "Secondary Path" pre-nominated (defined by human b= eing at the time of configuration) OR are they dynamically changed depending on which path is up at any given point in time, & which one came up later = etc?


=A0

User Adaptation (General):

=A0

UA 1) What is the exact meaning of "proper management" of streams in UA layer?

For example: RFC 4165: It is the responsibility of t= he M2PA layer to ensure proper management of the streams allowed within each association. Another example of this is in 1.5.4.1 of RFC 3331 (M2UA) which states: "SCTP allows a user specified number of streams to be opened during initialization of the association.=A0 It is the responsibility of th= e M2UA layer to ensure proper management of these streams.=A0 Because of the unidirectional nature of streams, a M2UA layer is not aware of the stream information from its peer M2UA layer (our query is WHY SHOULD IT BE AWARE??).=A0 For this reason, the Interface Identifier is in the M2UA message header"; perhaps, the NEED for communicating the INTERFACE ID = from one M2UA to its PEER also arises from this "responsibility" that = M2UA (or any adaptation layer - for that matter) must PROPERLY MANAGE the Stream= s - - is that correct?? If so, the question of "what is 'proper manage= ment' becomes more crucial!!

=A0

UA 2) Definition of "IPSP" in RFC4666 (M3U= A) & RFC 3868 SUA refers to IP Server Process where as in RFC4165 (M2PA) refers = to IP Signalling Point. Is it an error that same accronym has been used in

different RFCs to represent entities or is there a p= oint that we are missing?

Moreover in RFC3331 (M2UA) it is completely absent -= it keeps refering to MGC; can we not say that MGC is also an IPSP (to us IPSP appears to be a more generic term than MGC, Is it correct?).It is understandable that IPSP as a term is missing as a term for SCTP.

=A0

UA 3) We find that definition of SG in various RFCs = is broadly similar with minor variations (e.g. M3UA states that SG has a Point Code, while M2UA does not naturally have any reference to Point Code). We a= re a bit concerned and confused as to why IETF has chosen to make definitions RF= C specific.

=A0

M2PA:

=A0

M2PA 1) RFC 4165: 4.1.2

Figure 10.=A0 Multiple Associations Between Two IP Addresses

are there any guidelines for choosing "pre-sele= cted port number"? (P1)

=A0

M2PA 2) RFC 4165: 4.1.4

Processor Outage

M2PA (at both the LPO and RPO ends) uses the BSN val= ue in the received Link Status Ready message to resynchronize its sequence number= s, if this is required by MTP2.=A0 M2PA SHALL NOT resume transmitting User Dat= a messages until it has sent the Link Status Ready message. Why does it menti= on MTP2?

=A0

M2PA 3) RFC 4165: 4.1.5: Flow Control

When the peer M2PA receives the first Link Status Bu= sy message, it SHALL start the Remote Congestion timer T6 if there are message= s in the retransmission buffer awaiting acknowledgement (i.e., T7 is running).= =A0 M2PA SHALL stop the T7 timer if it is running.=A0 Additional Link Status Busy messages received while T6 is running do not cause T6 to be reset and = do not cause T7 to be started.=A0 While T6 is running, T7 SHALL NOT be started= . When the peer M2PA receives the Link Status Busy Ended message and T6 has n= ot expired, it SHALL stop T6 (if T6 is running) and start T7 (if there are messages awaiting acknowledgement in the retransmission buffer).

=A0

M2PA 4) Do you recall in RFC 4165 (or any other RFC)= a reference to SSN being used as a parameter for =A0"Changeover" with most significant 8 bits being set to zero? Is there a relation between= FSN / BSN of M2PA and TSN / SSN of SCTP?

=A0

=A0

M2UA:

M2UA 1) While using M2UA, is there a restriction t= hat on SS7 side of an SG, there can be only "one type" of node (say, = PSTN Classical Switch) and on IP side of THAT SG, there can be only "one type" of=A0node (say, MGC)? In one of tutorials (ZYTRAX), we ha= ve come across an expression that says: "The whole IP network is represented b= y a single point code that addresses the MGC at the network edge. Therefore all messages from the SS7 side going to the IP side are sent to the MGC through= the SG. Do you agree with this statement? If yes, is that UNCONDITIONAL or this statement is true only under certain environment (like M2UA)?? Is ZYTRAX, f= or example, making this statement only for a certain scenario - where M2UA is deployed for connecting up (say) PSTN SS7 node with MGC?

=A0

M2UA 2) While using M2UA, is there a restriction that on SS7 side of an SG, there can be only "one type" of node (say, PSTN Classical Switch) and on IP side of THAT SG, there can be only "one type" of

=A0

M2UA 3) In the RFC, it is stated that the M2UA SPECI= FIC HEADER is present IF AT ALL only for MAUP Message Class; however, it goes o= n to say that it may or may NOT be present in even when the message is an MAUP (MTP-2 User Adaptation Messages / Protocol??) messages. Thus, after Common Header, DIRECTLY, parameters may follow in T-L-V format.

(i)=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Is it prescribed as to WHEN this can be (should be) absent, & when not - - e.g. does Message Type automatically give an= y clue for this??

(ii)<= span style=3D"font:7.0pt "Times New Roman"">=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 How does the RECEIVING ENTITY come to know whether the M2UA specific header is present or not - - -is it by looking at= the TWO BYTES that follow "end of COMMON HEADER (message length)", &a= mp; if the value therein is "01 (Hex) - indicating Integar Value for IId", THEN CONCLUDE that the (M2UA specific) header is present & I= F IT IS ANYTHING OTHER THAN 01H (or, of course, 03H for ANSI Networks), then TRY= TO INTERPRET the same as a "Parameter Tag"??

=A0

M2UA 3) In one of the (SS7 =96 with INTRO to SIGTRAN= ) training sessions that we held last month, one of the trainees informed us that they have =93deployed=94 M2UA in the sense that they have a CLUSTER OF BLADE SER= VERS in their MGC. All those blades are represented by a SINGLE SIGNALLING POINT CO= DE, but EACH has a unique GT. The M2UA is used INTERNALLY between the SS7 front= end (the =93master server=94- so to say), & the =93back-end=94 cluster of B= lade Servers. Is this a typical usage that you have seen too (we ask this becaus= e it is usually very rare to SEE / get an example of, an M2UA deployment !!)?

=A0

=A0

M3UA:

=A0

M3UA 1) Section 1.1, Terminologies, states =93Where = an SG contains more than one SGP, the SG is a logical entity, and the contained S= GPs are assumed to be coordinated into a single management view t= o the SS7 network and to the supported Application Servers=94.=A0 We are confused about what the underlined part means.

=A0

M3UA 2) RFC also states that =93An IPSP is essential= ly the same as an ASP, except that it uses M3UA in a point-to-point fashion<= /u>.=94 What does =93point-to-point=94 mean?

=A0

M3UA 3) Routing Context is a 4 =96 byte number havin= g a one-to-one relationship with Routing Key. Moreover, Routing context is also transmitted from 1 node to the other as part of the message. Is it correct = to interpret that Routing Context is something similar to =93Translation Type= =94 use in SCCP =96 meaning possibly that the receiving node indexes a =93 (specifi= c / desired) table=94 basis the received RC value, & LOOKS for Routing Key = within that table?


Thanks= and Regards,

Aditi

--002215048a632bd21e04a9fabce9-- From bidulock@openss7.org Mon Aug 8 14:10:27 2011 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A87B21F8BE5 for ; Mon, 8 Aug 2011 14:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-3yxmLdmOuA for ; Mon, 8 Aug 2011 14:10:26 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.117.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1F96621F8BDB for ; Mon, 8 Aug 2011 14:10:25 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p78LAjGG008625; Mon, 8 Aug 2011 15:10:45 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p78LAjre016679; Mon, 8 Aug 2011 15:10:45 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p78LAi6o016678; Mon, 8 Aug 2011 15:10:44 -0600 Date: Mon, 8 Aug 2011 15:10:44 -0600 From: "Brian F. G. Bidulock" To: aditi someshwar Message-ID: <20110808211044.GA15848@openss7.org> Mail-Followup-To: aditi someshwar , sigtran@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA - Clarification on RFC 1.3.2.1 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 21:10:27 -0000 aditi, Well, no, the purpose is to extend the MTP/MTP-User interface from one host to another. To do so, transporting the primitive is required, not just the payload of the primitive. --brian aditi someshwar wrote: (Mon, 08 Aug 2011 13:47:42) > RFC4666 > > 1.3.2.1. Support for the Transport of MTP3-User Messages > > Fact (Quote): The M3UA layer provides the transport of MTP-TRANSFER > primitives across an established SCTP association between an SGP and an > ASP or between IPSPs. > > QUERY: The RFC seems to suggest that "MTP-TRANSFER PRIMITIVE itself" is > transported between NODE-A & NODE-B; our belief is that the > "CONSEQUENCE(result)" of having acted upon a primitive is what is > transported - - meaning that the PAYLOAD passed over by the "MTP-3 > User" under the primitive "MTP-TRANSFER" is what gets transported. > > COMMENT: In a LOGICAL sense, OF COURSE, it would mean that when AT THE > SENDING NODE, the "MTP-3 User" passes down a PAYLOAD to its LOCAL > M3UA (requesting for its TRANSPORT to the remote nodeB), the M3UA > does ACTION this, & with help from SCTP, causes this PAYLOAD to be > transported across. At the receiving node, the M3UA shall get the > PAYLOAD from its local SCTP, which it will in-turn handover to the > UL {"MTP-3 User at node B"}. TO THAT EXTENT, use of the phrase > "transports MTP- TRANSFER PRIMITIVE" is perhaps understandable, BUT > the fact remains that it is confusing!!! > > > > Any Comments please??? > > Regards, > > Aditi > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From bidulock@openss7.org Mon Aug 8 14:54:23 2011 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C774021F8C21 for ; Mon, 8 Aug 2011 14:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfHpigKx3BWA for ; Mon, 8 Aug 2011 14:54:22 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.117.178]) by ietfa.amsl.com (Postfix) with ESMTP id 65F5C21F8C15 for ; Mon, 8 Aug 2011 14:54:16 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p78LseLG008815; Mon, 8 Aug 2011 15:54:40 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p78LsduO021242; Mon, 8 Aug 2011 15:54:39 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p78Lsdjh021241; Mon, 8 Aug 2011 15:54:39 -0600 Date: Mon, 8 Aug 2011 15:54:39 -0600 From: "Brian F. G. Bidulock" To: aditi someshwar Message-ID: <20110808215439.GB15848@openss7.org> Mail-Followup-To: aditi someshwar , sigtran@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sigtran@ietf.org Subject: Re: [Sigtran] SIGTRAN specs: Some doubts X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 21:54:23 -0000 aditi, aditi someshwar wrote: (Mon, 08 Aug 2011 14:34:30) > Hi, > > We are a "Telecom Training Group" based out of India. Listed below, are > few doubts from our study of the SIGTRAN RFC documents. We would be > grateful if you can contribute with the clarifications. > > The list of queries is long, and we have segregated the points as per > the SIGTRAN topics.. you may like to address any point that you are > clear about. > > SCTP: > > > SCTP 1) We have understood that there are three mechanisms of > RE-TRANSMISSION > > (i) One governed by TIMER that is started each time > any message is sent (within this timer, an ACK must arrive for the > UDM); Well, no. The time is started when a message is sent when it is not already running. That is different than on each message. There are a number of other conditions under which the timer should be started, such as on a reneged TSN when no other data is in flight (i.e. the timer is not running). > (ii) If for a given message, an indication is received > FOUR TIMES CONSECUTIVELY in the SACK that "so & so" message is a > missing sequence case; (iii) under CHANGEOVER. Is that correct, OR are > > (iii) there any more conditions that we have missed? That is a simplification of the major two. Some others: - Retransmission can be invoked when a destination is deemed failed and there is data outstanding to that destination. - Retransmission is invoked when the peer renegs on an TSN. There are probably more. Also, there are a number of instances under CMT where retransmissions of the first two varieties need to be suppressed to avoid excessive spurious retransmissions. > Having concluded that RE-TRANSMISSION has to be done, is there a > MANDATE that such RE-TRANSMISSIONs must be done using SECONDARY PATH > (for the same association) even when the PRIMARY PATH is healthy? Are > "Primary Path" and "Secondary Path" pre-nominated (defined by human > being at the time of configuration) OR are they dynamically changed > depending on which path is up at any given point in time, & which one > came up later etc? This is an entire field of study. > > User Adaptation (General): > > > UA 1) What is the exact meaning of "proper management" of streams in UA > layer? > > For example: RFC 4165: It is the responsibility of the M2PA layer to > ensure proper management of the streams allowed within each > association. Another example of this is in 1.5.4.1 of RFC 3331 (M2UA) > which states: "SCTP allows a user specified number of streams to be > opened during initialization of the association. It is the > responsibility of the M2UA layer to ensure proper management of these > streams. Because of the unidirectional nature of streams, a M2UA layer > is not aware of the stream information from its peer M2UA layer (our > query is WHY SHOULD IT BE AWARE??). For this reason, the Interface > Identifier is in the M2UA message header"; perhaps, the NEED for > communicating the INTERFACE ID from one M2UA to its PEER also arises > from this "responsibility" that M2UA (or any adaptation layer - for > that matter) must PROPERLY MANAGE the Streams - - is that correct?? If > so, the question of "what is 'proper management' becomes more crucial!! Management of stream consists of requesting and negotiating the number of inbound and outbound streams with the peer, and then selecting the stream on which to transmit a given message considering the sequence requirements of the message flows. > UA 2) Definition of "IPSP" in RFC4666 (M3UA) & RFC 3868 SUA refers to > IP Server Process where as in RFC4165 (M2PA) refers to IP Signalling > Point. Is it an error that same accronym has been used in > different RFCs to represent entities or is there a point that we are > missing? M2PA and M3UA are different. M2PA represents a signalling link. The entities at either end of a signalling link must be a signalling point. In M3UA there is no such requirement, it can be a process on a host. > Moreover in RFC3331 (M2UA) it is completely absent - it keeps refering > to MGC; can we not say that MGC is also an IPSP (to us IPSP appears to > be a more generic term than MGC, Is it correct?).It is understandable > that IPSP as a term is missing as a term for SCTP. No, IPSP is a SIGTRAN term, not an SCTP term. It is defined in the RFC in which it is used. > UA 3) We find that definition of SG in various RFCs is broadly similar > with minor variations (e.g. M3UA states that SG has a Point Code, while > M2UA does not naturally have any reference to Point Code). We are a bit > concerned and confused as to why IETF has chosen to make definitions > RFC specific. Because the RFCs are different and operate at different levels of the SS7 stack. M3UA transport MTP/MTP-User (Level 3) interface primitive. For MTP (Level 3) the MTP-Entity-Identifier is a point code. M2UA operates at MTP Level 2. The identifier for a signalling terminal is a signalling terminal identifier and/or signalling data link identifier. The interface identifier is used in this manner. > M2PA: > > > M2PA 1) RFC 4165: 4.1.2 > > Figure 10. Multiple Associations Between Two IP Addresses > are there any guidelines for choosing "pre-selected port number"? (P1) Yes, the well-known M3UA port number. > M2PA 2) RFC 4165: 4.1.4 > > Processor Outage > > M2PA (at both the LPO and RPO ends) uses the BSN value in the received > Link Status Ready message to resynchronize its sequence numbers, if > this is required by MTP2. M2PA SHALL NOT resume transmitting User Data > messages until it has sent the Link Status Ready message. Why does it > mention MTP2? Because we did not want to transcribe each of or any of the international nor 49 national flavors of MTP2 specifiacations into the document. > M2PA 3) RFC 4165: 4.1.5: Flow Control > > When the peer M2PA receives the first Link Status Busy message, it > SHALL start the Remote Congestion timer T6 if there are messages in the > retransmission buffer awaiting acknowledgement (i.e., T7 is running). > M2PA SHALL stop the T7 timer if it is running. Additional Link Status > Busy messages received while T6 is running do not cause T6 to be reset > and do not cause T7 to be started. While T6 is running, T7 SHALL NOT > be started. When the peer M2PA receives the Link Status Busy Ended > message and T6 has not expired, it SHALL stop T6 (if T6 is running) and > start T7 (if there are messages awaiting acknowledgement in the > retransmission buffer). Is there a question in there? > M2PA 4) Do you recall in RFC 4165 (or any other RFC) a reference to SSN > being used as a parameter for "Changeover" with most significant 8 > bits being set to zero? Is there a relation between FSN / BSN of M2PA > and TSN / SSN of SCTP? Only 24-bits are significant because the XCO/XCA can only accept 24 bits. There is no relationship between FSN/BSN and TSN/SSN. > M2UA: > M2UA 1) While using M2UA, is there a restriction that on SS7 side of an > SG, there can be only "one type" of node (say, PSTN Classical Switch) > and on IP side of THAT SG, there can be only "one type" of node (say, > MGC)? In one of tutorials (ZYTRAX), we have come across an expression > that says: "The whole IP network is represented by a single point code > that addresses the MGC at the network edge. Therefore all messages from > the SS7 side going to the IP side are sent to the MGC through the SG. > Do you agree with this statement? If yes, is that UNCONDITIONAL or this > statement is true only under certain environment (like M2UA)?? Is > ZYTRAX, for example, making this statement only for a certain scenario > - where M2UA is deployed for connecting up (say) PSTN SS7 node with > MGC? M2UA has no IPSP mode, just ASP/SG mode. M2PA is used where you would want to use M2UA for IPSP. > M2UA 2) While using M2UA, is there a restriction that on SS7 side of an > SG, there can be only "one type" of node (say, PSTN Classical Switch) > and on IP side of THAT SG, there can be only "one type" of Same as above. > M2UA 3) In the RFC, it is stated that the M2UA SPECIFIC HEADER is > present IF AT ALL only for MAUP Message Class; however, it goes on to > say that it may or may NOT be present in even when the message is an > MAUP (MTP-2 User Adaptation Messages / Protocol??) messages. Thus, > after Common Header, DIRECTLY, parameters may follow in T-L-V format. > > (i) Is it prescribed as to WHEN this can be (should > be) absent, & when not - - e.g. does Message Type automatically give > any clue for this?? It is detailed in the message format of each message in the RFC. > (ii) How does the RECEIVING ENTITY come to know whether > the M2UA specific header is present or not - - -is it by looking at the > TWO BYTES that follow "end of COMMON HEADER (message length)", & if the > value therein is "01 (Hex) - indicating Integar Value for IId", THEN > CONCLUDE that the (M2UA specific) header is present & IF IT IS ANYTHING > OTHER THAN 01H (or, of course, 03H for ANSI Networks), then TRY TO > INTERPRET the same as a "Parameter Tag"?? The header is not optional: it is included in some message types and not in others. The message type determines whether the header must be there or not. > M2UA 3) In one of the (SS7 with INTRO to SIGTRAN) training sessions > that we held last month, one of the trainees informed us that they have > deployed M2UA in the sense that they have a CLUSTER OF BLADE SERVERS in > their MGC. All those blades are represented by a SINGLE SIGNALLING > POINT CODE, but EACH has a unique GT. The M2UA is used INTERNALLY > between the SS7 front end (the master server- so to say), & the > back-end cluster of Blade Servers. Is this a typical usage that you > have seen too (we ask this because it is usually very rare to SEE / get > an example of, an M2UA deployment !!)? M2UA served a purpose for legacy arrangements that is not so prevalent any more. Nevertheless, ETSI/3GPP proscribes is use in a number of scenarios. > M3UA: > > M3UA 1) Section 1.1, Terminologies, states Where an SG contains more > than one SGP, the SG is a logical entity, and the contained SGPs are > assumed to be coordinated into a single management view to the SS7 > network and to the supported Application Servers. We are confused > about what the underlined part means. An SG has a point code, regardless of the number of SGPs providing identical access to the SS7 network through that point code. Remember that a point code is an MTP-Level3-Entity-Identifier in the SS7 network. > M3UA 2) RFC also states that An IPSP is essentially the same as an ASP, > except that it uses M3UA in a point-to-point fashion. What does > point-to-point mean? One IPSP is at one MTP end-point, the other is at the other MTP end-point. There is no relay point (STP), or other MTP entity between them. They are used in this point-to-point fashion. > M3UA 3) Routing Context is a 4 byte number having a one-to-one > relationship with Routing Key. Moreover, Routing context is also > transmitted from 1 node to the other as part of the message. Is it > correct to interpret that Routing Context is something similar to > Translation Type use in SCCP meaning possibly that the receiving node > indexes a (specific / desired) table basis the received RC value, & > LOOKS for Routing Key within that table? It has no relation to TT. It is closer to the concept of a combined routeset under MTP. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From ashima.gera@gmail.com Sat Aug 13 22:12:36 2011 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA6121F86C0 for ; Sat, 13 Aug 2011 22:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlpx4RoX4r70 for ; Sat, 13 Aug 2011 22:12:35 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABBB21F8634 for ; Sat, 13 Aug 2011 22:12:34 -0700 (PDT) Received: by gyf3 with SMTP id 3so3167472gyf.31 for ; Sat, 13 Aug 2011 22:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=WOJAz31a6+/AkpHrVd0WlJYsJpEdzWgUPAOAL2Rh6Y8=; b=BaGG08tEmFi5UpzPEqlhmxWh8c7RBBvHa2E6V2X5wnnwGzUhfQ6kPHBjrrdtaj0Vma fFpitg1npQ/VEQu2slotEHL6T6fMv5rDqMqIH5etphArCN/rB7t45mToT4+nTyXXusIO IZG+XbUE8vLiqDNb7UsRlfMT15hfPcmNDOc6w= MIME-Version: 1.0 Received: by 10.150.31.11 with SMTP id e11mr3613468ybe.129.1313298796646; Sat, 13 Aug 2011 22:13:16 -0700 (PDT) Received: by 10.151.43.20 with HTTP; Sat, 13 Aug 2011 22:13:16 -0700 (PDT) Date: Sun, 14 Aug 2011 10:43:16 +0530 Message-ID: From: ashima gera To: sigtran@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Sigtran] SUA : Query X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 05:12:36 -0000 Hello, I have a query, (a) Which layers of an SS7 incoming message (Say a MAP/ CAP Message) does a Signaling Gateway open as a part of the decision making process for determining its routing towards the IP world connected over SUA? (b) Does it restrict itself only upto the SCCP layer or does it open TCAP/MAP/CAP also ? It appears that the CISCO product - ITP does open the upper layers {typically in the case where IP SCPs are in a Cluster and the first message is routed to any of the eligible SCPs while subsequent messages for the same call context are to be routed (naturally) to the same SCP node as the first message} ? Is this behavior only CISCO specific or is it mandated by the IETF ? If it does not open any layer above the SCCP layer, what is the mechanism by which a general (non CISCO) Signaling Gateway achieves the same routing methodology as described in para 'b' above ? Thanks in anticipation for your response ! Ashima From bidulock@openss7.org Sun Aug 14 17:51:21 2011 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA0D11E809A for ; Sun, 14 Aug 2011 17:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ev+lJ3v4hffY for ; Sun, 14 Aug 2011 17:51:21 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.117.178]) by ietfa.amsl.com (Postfix) with ESMTP id 8C22211E8094 for ; Sun, 14 Aug 2011 17:51:19 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p7F0pxxQ017005; Sun, 14 Aug 2011 18:51:59 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p7F0px4E031547; Sun, 14 Aug 2011 18:51:59 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p7F0pxd9031540; Sun, 14 Aug 2011 18:51:59 -0600 Date: Sun, 14 Aug 2011 18:51:59 -0600 From: "Brian F. G. Bidulock" To: ashima gera Message-ID: <20110815005159.GA30510@openss7.org> Mail-Followup-To: ashima gera , sigtran@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sigtran@ietf.org Subject: Re: [Sigtran] SUA : Query X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 00:51:21 -0000 Ashima, Read RFC 3868 Section 4.7.3 and especially 4.7.3.1. Note that it is considered bad form to discuss a particular vendor's products (and identifying them by name) here. Most vendors have some other forum on which you can better discuss the features of their products. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From aditi.someshwar@gmail.com Tue Aug 16 02:34:15 2011 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD93821F8B61 for ; Tue, 16 Aug 2011 02:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=-1.387, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELTYBZs5baku for ; Tue, 16 Aug 2011 02:34:13 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8C721F8B5D for ; Tue, 16 Aug 2011 02:34:13 -0700 (PDT) Received: by iye1 with SMTP id 1so8814002iye.27 for ; Tue, 16 Aug 2011 02:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OmrY5+ojUZepV3DEVeNKHcFaLIYn55JaYSfXGS5WyrY=; b=rK+TQZysytSMRVfZVeoxtOiWJ50oJ9XfvUj8BahIz6W/bOgtESyf1U8m6toNa5Ltzk KaBNtR0C6J+dUhxqyACTDExzjUQL6UmtOrO82xHF2G/qUWlq22IW/eIWT5OorlfuLADB DJYRtobUY7a3O+a5O6XzgPESq7oBLxvXM1rdo= MIME-Version: 1.0 Received: by 10.231.21.194 with SMTP id k2mr7859534ibb.2.1313487301343; Tue, 16 Aug 2011 02:35:01 -0700 (PDT) Received: by 10.231.14.4 with HTTP; Tue, 16 Aug 2011 02:35:01 -0700 (PDT) In-Reply-To: <20110808215439.GB15848@openss7.org> References: <20110808215439.GB15848@openss7.org> Date: Tue, 16 Aug 2011 15:05:01 +0530 Message-ID: From: aditi someshwar To: bidulock@openss7.org, sigtran@ietf.org Content-Type: multipart/alternative; boundary=00151773db9a0379ce04aa9c183b Subject: Re: [Sigtran] SIGTRAN specs: Some doubts X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 09:34:16 -0000 --00151773db9a0379ce04aa9c183b Content-Type: text/plain; charset=ISO-8859-1 Brian, Thank you very much for the Clarifications. Have put in responses to two points below (in green), if you can please give your views. Thanks and Regards, Aditi On Tue, Aug 9, 2011 at 3:24 AM, Brian F. G. Bidulock wrote: > aditi, > > aditi someshwar wrote: > > (Mon, > 08 Aug 2011 14:34:30) > > Hi, > > > > We are a "Telecom Training Group" based out of India. Listed below, > are > > few doubts from our study of the SIGTRAN RFC documents. We would be > > grateful if you can contribute with the clarifications. > > > > The list of queries is long, and we have segregated the points as per > > the SIGTRAN topics.. you may like to address any point that you are > > clear about. > > > > SCTP: > > > > > > SCTP 1) We have understood that there are three mechanisms of > > RE-TRANSMISSION > > > > (i) One governed by TIMER that is started each time > > any message is sent (within this timer, an ACK must arrive for the > > UDM); > > Well, no. The time is started when a message is sent when it is not > already running. That is different than on each message. There are > a number of other conditions under which the timer should be started, > such as on a reneged TSN when no other data is in flight (i.e. the > timer is not running). > *Aditi:* *The BLOW UP of this {& hence, to elaborate on the exact question we have}, the following hypothetical example is perhaps the best way:* *A. - - - >>> (Just to keep matters simple) We shall assume that ONLY ONE NODE has any messages to send; Node B has none.* *B. - - >>> Assume that the "need" for sending the FIRST message (say, with TSN = 240) arose at exactly 14:00 hrs on 09 Aug 2011. Let us also assume (for simplicity again) that no timer was running. When Node A (i.e its SCTP) sends TSN = 249, we presume that a TIMER T shall now be started. Just to bring out out exact query more clearly, let us assume that timer is 60 Minutes (!!). Now, let us further assume that Node A keeps getting a "need" to send a (fresh) message every 1 minute, for next 40 minutes (& after that, it too has no more FRESH messages to send - - ASSUME, for simplicity again). We are making some statements below - EACH of which needs to be confirmed or modified ::::* *C. - - - >>>> When TSN = 241 is sent (at 14:01 hrs / 09 Aug 2011), TIMER T shall be RESET (so now it will "blow the whistle at 15:01 hrs, rather than at 15;00 hrs IF IT HAD NOT BEEN RESET).* *D. - - - >>> When, similarly, TSN = 242 is sent, the timer T is AGAIN reset & so on. So, when TSN = 299 is sent (at 14:40 hrs / 09 Aug 2011), it shall be "set" to "blow its whistle" at 15:40 hrs.* *E1. (scenario 1)- - - >>> Assume that ALL TSNs get ACKed (whether sequentially or otherwise) before 14:50 hrs / 09 Aug 2011, THEN, according to our belief, timer T shall be RESET TO PASSIVE MODE in "not active mode (not counting any-more); such RESET shall occur according to us at the instant LAST of the ACKs is received. In this example (scenario), NO RETRANSMISSION shall occur owing to "blowing up of the timer T's whistle".* *E2. (scenario 2) - - - >>> Assume that ALL TSNs BUT TSNs 244, 256 & 299 get ACKed (whether sequentially or otherwise) upto 15:40 hrs / 09 Aug 2011, THEN, according to our belief, timer T shall "blow up its whistle", & post that, ONLY these three TSNs shall be RE-TRANSMITTED* *Is the above understanding correct?* > > > (ii) If for a given message, an indication is received > > FOUR TIMES CONSECUTIVELY in the SACK that "so & so" message is a > > missing sequence case; (iii) under CHANGEOVER. Is that correct, OR are > > > > (iii) there any more conditions that we have missed? > > That is a simplification of the major two. Some others: > > - Retransmission can be invoked when a destination is deemed failed and > there is data outstanding to that destination. > > - Retransmission is invoked when the peer renegs on an TSN. > > There are probably more. Also, there are a number of instances under > CMT where retransmissions of the first two varieties need to be > suppressed to avoid excessive spurious retransmissions. > > > Having concluded that RE-TRANSMISSION has to be done, is there a > > MANDATE that such RE-TRANSMISSIONs must be done using SECONDARY PATH > > (for the same association) even when the PRIMARY PATH is healthy? Are > > "Primary Path" and "Secondary Path" pre-nominated (defined by human > > being at the time of configuration) OR are they dynamically changed > > depending on which path is up at any given point in time, & which one > > came up later etc? > > This is an entire field of study. > > > > > User Adaptation (General): > > > > > > UA 1) What is the exact meaning of "proper management" of streams in > UA > > layer? > > > > For example: RFC 4165: It is the responsibility of the M2PA layer to > > ensure proper management of the streams allowed within each > > association. Another example of this is in 1.5.4.1 of RFC 3331 (M2UA) > > which states: "SCTP allows a user specified number of streams to be > > opened during initialization of the association. It is the > > responsibility of the M2UA layer to ensure proper management of these > > streams. Because of the unidirectional nature of streams, a M2UA > layer > > is not aware of the stream information from its peer M2UA layer (our > > query is WHY SHOULD IT BE AWARE??). For this reason, the Interface > > Identifier is in the M2UA message header"; perhaps, the NEED for > > communicating the INTERFACE ID from one M2UA to its PEER also arises > > from this "responsibility" that M2UA (or any adaptation layer - for > > that matter) must PROPERLY MANAGE the Streams - - is that correct?? If > > so, the question of "what is 'proper management' becomes more > crucial!! > > Management of stream consists of requesting and negotiating the number > of inbound and outbound streams with the peer, and then selecting the > stream on which to transmit a given message considering the sequence > requirements of the message flows. > > > UA 2) Definition of "IPSP" in RFC4666 (M3UA) & RFC 3868 SUA refers to > > IP Server Process where as in RFC4165 (M2PA) refers to IP Signalling > > Point. Is it an error that same accronym has been used in > > different RFCs to represent entities or is there a point that we are > > missing? > > M2PA and M3UA are different. M2PA represents a signalling link. The > entities at either end of a signalling link must be a signalling point. > In M3UA there is no such requirement, it can be a process on a host. > > > Moreover in RFC3331 (M2UA) it is completely absent - it keeps refering > > to MGC; can we not say that MGC is also an IPSP (to us IPSP appears to > > be a more generic term than MGC, Is it correct?).It is understandable > > that IPSP as a term is missing as a term for SCTP. > > No, IPSP is a SIGTRAN term, not an SCTP term. It is defined in the RFC > in which it is used. > > > UA 3) We find that definition of SG in various RFCs is broadly similar > > with minor variations (e.g. M3UA states that SG has a Point Code, > while > > M2UA does not naturally have any reference to Point Code). We are a > bit > > concerned and confused as to why IETF has chosen to make definitions > > RFC specific. > > Because the RFCs are different and operate at different levels of the > SS7 stack. M3UA transport MTP/MTP-User (Level 3) interface primitive. > For MTP (Level 3) the MTP-Entity-Identifier is a point code. M2UA > operates at MTP Level 2. The identifier for a signalling terminal is > a signalling terminal identifier and/or signalling data link identifier. > The interface identifier is used in this manner. > > > M2PA: > > > > > > M2PA 1) RFC 4165: 4.1.2 > > > > Figure 10. Multiple Associations Between Two IP Addresses > > are there any guidelines for choosing "pre-selected port number"? (P1) > > Yes, the well-known M3UA port number. > > > M2PA 2) RFC 4165: 4.1.4 > > > > Processor Outage > > > > M2PA (at both the LPO and RPO ends) uses the BSN value in the received > > Link Status Ready message to resynchronize its sequence numbers, if > > this is required by MTP2. M2PA SHALL NOT resume transmitting User > Data > > messages until it has sent the Link Status Ready message. Why does it > > mention MTP2? > > Because we did not want to transcribe each of or any of the > international nor 49 national flavors of MTP2 specifiacations into the > document. > > > M2PA 3) RFC 4165: 4.1.5: Flow Control > > > > When the peer M2PA receives the first Link Status Busy message, it > > SHALL start the Remote Congestion timer T6 if there are messages in > the > > retransmission buffer awaiting acknowledgement (i.e., T7 is running). > > M2PA SHALL stop the T7 timer if it is running. Additional Link Status > > Busy messages received while T6 is running do not cause T6 to be reset > > and do not cause T7 to be started. While T6 is running, T7 SHALL NOT > > be started. When the peer M2PA receives the Link Status Busy Ended > > message and T6 has not expired, it SHALL stop T6 (if T6 is running) > and > > start T7 (if there are messages awaiting acknowledgement in the > > retransmission buffer). > > Is there a question in there? > > > M2PA 4) Do you recall in RFC 4165 (or any other RFC) a reference to > SSN > > being used as a parameter for "Changeover" with most significant 8 > > bits being set to zero? Is there a relation between FSN / BSN of M2PA > > and TSN / SSN of SCTP? > > Only 24-bits are significant because the XCO/XCA can only accept 24 > bits. There is no relationship between FSN/BSN and TSN/SSN. > > > M2UA: > > M2UA 1) While using M2UA, is there a restriction that on SS7 side of > an > > SG, there can be only "one type" of node (say, PSTN Classical Switch) > > and on IP side of THAT SG, there can be only "one type" of node (say, > > MGC)? In one of tutorials (ZYTRAX), we have come across an expression > > that says: "The whole IP network is represented by a single point code > > that addresses the MGC at the network edge. Therefore all messages > from > > the SS7 side going to the IP side are sent to the MGC through the SG. > > Do you agree with this statement? If yes, is that UNCONDITIONAL or > this > > statement is true only under certain environment (like M2UA)?? Is > > ZYTRAX, for example, making this statement only for a certain scenario > > - where M2UA is deployed for connecting up (say) PSTN SS7 node with > > MGC? > > M2UA has no IPSP mode, just ASP/SG mode. M2PA is used where you would > want to use M2UA for IPSP. > *Aditi: Can you tell us the difference between IPSP and ASP? * > > > M2UA 2) While using M2UA, is there a restriction that on SS7 side of > an > > SG, there can be only "one type" of node (say, PSTN Classical Switch) > > and on IP side of THAT SG, there can be only "one type" of > > Same as above. > > > M2UA 3) In the RFC, it is stated that the M2UA SPECIFIC HEADER is > > present IF AT ALL only for MAUP Message Class; however, it goes on to > > say that it may or may NOT be present in even when the message is an > > MAUP (MTP-2 User Adaptation Messages / Protocol??) messages. Thus, > > after Common Header, DIRECTLY, parameters may follow in T-L-V format. > > > > (i) Is it prescribed as to WHEN this can be (should > > be) absent, & when not - - e.g. does Message Type automatically give > > any clue for this?? > > It is detailed in the message format of each message in the RFC. > > > (ii) How does the RECEIVING ENTITY come to know whether > > the M2UA specific header is present or not - - -is it by looking at > the > > TWO BYTES that follow "end of COMMON HEADER (message length)", & if > the > > value therein is "01 (Hex) - indicating Integar Value for IId", THEN > > CONCLUDE that the (M2UA specific) header is present & IF IT IS > ANYTHING > > OTHER THAN 01H (or, of course, 03H for ANSI Networks), then TRY TO > > INTERPRET the same as a "Parameter Tag"?? > > The header is not optional: it is included in some message types and not > in others. The message type determines whether the header must be there > or not. > > > M2UA 3) In one of the (SS7 with INTRO to SIGTRAN) training sessions > > that we held last month, one of the trainees informed us that they > have > > deployed M2UA in the sense that they have a CLUSTER OF BLADE SERVERS > in > > their MGC. All those blades are represented by a SINGLE SIGNALLING > > POINT CODE, but EACH has a unique GT. The M2UA is used INTERNALLY > > between the SS7 front end (the master server- so to say), & the > > back-end cluster of Blade Servers. Is this a typical usage that you > > have seen too (we ask this because it is usually very rare to SEE / > get > > an example of, an M2UA deployment !!)? > > M2UA served a purpose for legacy arrangements that is not so prevalent > any more. Nevertheless, ETSI/3GPP proscribes is use in a number of > scenarios. > > > M3UA: > > > > M3UA 1) Section 1.1, Terminologies, states Where an SG contains more > > than one SGP, the SG is a logical entity, and the contained SGPs are > > assumed to be coordinated into a single management view to the SS7 > > network and to the supported Application Servers. We are confused > > about what the underlined part means. > > An SG has a point code, regardless of the number of SGPs providing > identical access to the SS7 network through that point code. Remember > that a point code is an MTP-Level3-Entity-Identifier in the SS7 network. > > > M3UA 2) RFC also states that An IPSP is essentially the same as an > ASP, > > except that it uses M3UA in a point-to-point fashion. What does > > point-to-point mean? > > One IPSP is at one MTP end-point, the other is at the other MTP > end-point. There is no relay point (STP), or other MTP entity between > them. They are used in this point-to-point fashion. > > > M3UA 3) Routing Context is a 4 byte number having a one-to-one > > relationship with Routing Key. Moreover, Routing context is also > > transmitted from 1 node to the other as part of the message. Is it > > correct to interpret that Routing Context is something similar to > > Translation Type use in SCCP meaning possibly that the receiving node > > indexes a (specific / desired) table basis the received RC value, & > > LOOKS for Routing Key within that table? > > It has no relation to TT. It is closer to the concept of a combined > routeset under MTP. > > --brian > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > --00151773db9a0379ce04aa9c183b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Brian,

Thank you very much for the Clar= ifications.
Have put in responses to two = points below (in green), if you can please give your views.

Thanks and Regards, Aditi

On Tue, Aug 9, 2011 at 3:24 AM, Brian F. G. Bidulock <bidulock@openss7.org> wrote:
aditi,

aditi someshwar wrote: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(Mon, 08 Aug 2011 14:34:30)<= br>
> =A0 =A0Hi,
>
> =A0 =A0We are a "Telecom Training Group" based out of India.= Listed below, are
> =A0 =A0few doubts from our study of the SIGTRAN RFC documents. We woul= d be
> =A0 =A0grateful if you can contribute with the clarifications.
>
> =A0 =A0The list of queries is long, and we have segregated the points = as per
> =A0 =A0the SIGTRAN topics.. you may like to address any point that you= are
> =A0 =A0clear about.
>
> =A0 =A0SCTP:
>
>
> =A0 =A0SCTP 1) We have understood that there are three mechanisms of > =A0 =A0RE-TRANSMISSION
>
> =A0 =A0(i) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0One governed by TIMER th= at is started each time
> =A0 =A0any message is sent (within this timer, an ACK must arrive for = the
> =A0 =A0UDM);

Well, no. =A0The time is started when a message is sent when it is no= t
already running. =A0That is different than on each message. =A0There are a number of other conditions under which the timer should be started,
such as on a reneged TSN when no other data is in flight (i.e. the
timer is not running).

Aditi:

The BLOW UP of this {& hence, to elaborate on the exact question we have}, the following hypotheti= cal example is perhaps the best way:

=A0

A. - - - >>&g= t; (Just to keep matters simple) We shall assume that ONLY ONE NODE has any messages= to send; Node B has none.

=A0

B. - - >>>= Assume that the "need" for sending the FIRST message (say, with TSN =3D = 240) arose at exactly 14:00 hrs on 09 Aug 2011. Let us also assume (for simplici= ty again) that no timer was running. When Node A (i.e its SCTP) sends =A0TSN = =3D 249, we presume that a TIMER T shall now be started. Just to bring out out exact query more clearly, let us assume that timer is 60 Minutes (!!). Now,= let us further assume that Node A keeps getting a "need" to send a (fresh) message every 1 minute, for next 40 minutes (& after that, it t= oo has no more FRESH messages to send - - ASSUME, for simplicity again). We are ma= king some statements below - EACH of which needs to be confirmed or modified :::= :

=A0

C. - - - >>&g= t;> When TSN =3D 241 is sent (at 14:01 hrs / 09 Aug 2011), TIMER T shall be RES= ET (so now it will "blow the whistle at 15:01 hrs, rather than at 15;00 hrs I= F IT HAD NOT BEEN RESET).

=A0

D. - - - >>&g= t; When, similarly, TSN =3D 242 is sent, the timer T is AGAIN reset & so on. So,= when TSN =3D 299 is sent (at 14:40 hrs / 09 Aug 2011), it shall be "set&quo= t; to "blow its whistle" at 15:40 hrs.

=A0

E1. (scenario 1)- -= - >>> Assume that ALL TSNs get ACKed (whether sequentially or otherw= ise) before 14:50 hrs / 09 Aug 2011, THEN, according to our belief, timer T shal= l be RESET TO PASSIVE MODE in "not active mode (not counting any-more); suc= h RESET shall occur according to us at the instant LAST of the ACKs is receiv= ed. In this example (scenario), NO RETRANSMISSION shall occur owing to "blowing up of the timer T's whistle".

=A0

E2. (scenario 2) - - - >>> Assume that ALL TSNs BUT TSNs 244, 256 & 299 get ACKed (whether sequentially or otherwise) upto 15:40 hrs / 09 Aug 2011, =A0THEN, according to our belief, timer T shall =A0"blow up its whistle", & post that, ONLY these three TSNs shall be RE-TRANSMITTED= =A0

Is the above understanding correct?

> =A0 =A0(ii) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0If for a given message, an = indication is received
> =A0 =A0FOUR TIMES CONSECUTIVELY in the SACK that "so & so&quo= t; message is a
> =A0 =A0missing sequence case; (iii) under CHANGEOVER. Is that correct,= OR are
>
> =A0 =A0(iii) =A0 =A0 =A0 =A0 =A0 =A0 =A0 there any more conditions tha= t we have missed?

That is a simplification of the major two. =A0Some others:

- Retransmission can be invoked when a destination is deemed failed and
=A0there is data outstanding to that destination.

- Retransmission is invoked when the peer renegs on an TSN.

There are probably more. =A0Also, there are a number of instances under
CMT where retransmissions of the first two varieties need to be
suppressed to avoid excessive spurious retransmissions.

> =A0 =A0Having concluded =A0that RE-TRANSMISSION has to be done, is the= re a
> =A0 =A0MANDATE that such RE-TRANSMISSIONs must be done using SECONDARY= PATH
> =A0 =A0(for the same association) even when the PRIMARY PATH is health= y? Are
> =A0 =A0"Primary Path" and "Secondary Path" pre-nom= inated (defined by human
> =A0 =A0being at the time of configuration) OR are they dynamically cha= nged
> =A0 =A0depending on which path is up at any given point in time, &= which one
> =A0 =A0came up later etc?

This is an entire field of study.

>
> =A0 =A0User Adaptation (General):
>
>
> =A0 =A0UA 1) What is the exact meaning of "proper management"= ; of streams in UA
> =A0 =A0layer?
>
> =A0 =A0For example: RFC 4165: It is the responsibility of the M2PA lay= er to
> =A0 =A0ensure proper management of the streams allowed within each
> =A0 =A0association. Another example of this is in 1.5.4.1 of RFC 3331 = (M2UA)
> =A0 =A0which states: "SCTP allows a user specified number of stre= ams to be
> =A0 =A0opened during initialization of the association. =A0It is the > =A0 =A0responsibility of the M2UA layer to ensure proper management of= these
> =A0 =A0streams. =A0Because of the unidirectional nature of streams, a = M2UA layer
> =A0 =A0is not aware of the stream information from its peer M2UA layer= (our
> =A0 =A0query is WHY SHOULD IT BE AWARE??). =A0For this reason, the Int= erface
> =A0 =A0Identifier is in the M2UA message header"; perhaps, the NE= ED for
> =A0 =A0communicating the INTERFACE ID from one M2UA to its PEER also a= rises
> =A0 =A0from this "responsibility" that M2UA (or any adaptati= on layer - for
> =A0 =A0that matter) must PROPERLY MANAGE the Streams - - is that corre= ct?? If
> =A0 =A0so, the question of "what is 'proper management' b= ecomes more crucial!!

Management of stream consists of requesting and negotiating the numbe= r
of inbound and outbound streams with the peer, and then selecting the
stream on which to transmit a given message considering the sequence
requirements of the message flows.

> =A0 =A0UA 2) Definition of "IPSP" in RFC4666 (M3UA) & RF= C 3868 SUA refers to
> =A0 =A0IP Server Process where as in RFC4165 (M2PA) refers to IP Signa= lling
> =A0 =A0Point. Is it an error that same accronym has been used in
> =A0 =A0different RFCs to represent entities or is there a point that w= e are
> =A0 =A0missing?

M2PA and M3UA are different. =A0M2PA represents a signalling link. = =A0The
entities at either end of a signalling link must be a signalling point.
In M3UA there is no such requirement, it can be a process on a host.

> =A0 =A0Moreover in RFC3331 (M2UA) it is completely absent - it keeps r= efering
> =A0 =A0to MGC; can we not say that MGC is also an IPSP (to us IPSP app= ears to
> =A0 =A0be a more generic term than MGC, Is it correct?).It is understa= ndable
> =A0 =A0that IPSP as a term is missing as a term for SCTP.

No, IPSP is a SIGTRAN term, not an SCTP term. =A0It is defined in the= RFC
in which it is used.

> =A0 =A0UA 3) We find that definition of SG in various RFCs is broadly = similar
> =A0 =A0with minor variations (e.g. M3UA states that SG has a Point Cod= e, while
> =A0 =A0M2UA does not naturally have any reference to Point Code). We a= re a bit
> =A0 =A0concerned and confused as to why IETF has chosen to make defini= tions
> =A0 =A0RFC specific.

Because the RFCs are different and operate at different levels of the=
SS7 stack. =A0M3UA transport MTP/MTP-User (Level 3) interface primitive. For MTP (Level 3) the MTP-Entity-Identifier is a point code. =A0M2UA
operates at MTP Level 2. =A0The identifier for a signalling terminal is
a signalling terminal identifier and/or signalling data link identifier. The interface identifier is used in this manner.

> =A0 =A0M2PA:
>
>
> =A0 =A0M2PA 1) RFC 4165: 4.1.2
>
> =A0 =A0Figure 10. =A0Multiple Associations Between Two IP Addresses > =A0 =A0are there any guidelines for choosing "pre-selected port n= umber"? (P1)

Yes, the well-known M3UA port number.

> =A0 =A0M2PA 2) RFC 4165: 4.1.4
>
> =A0 =A0Processor Outage
>
> =A0 =A0M2PA (at both the LPO and RPO ends) uses the BSN value in the r= eceived
> =A0 =A0Link Status Ready message to resynchronize its sequence numbers= , if
> =A0 =A0this is required by MTP2. =A0M2PA SHALL NOT resume transmitting= User Data
> =A0 =A0messages until it has sent the Link Status Ready message. Why d= oes it
> =A0 =A0mention MTP2?

Because we did not want to transcribe each of or any of the
international nor 49 national flavors of MTP2 specifiacations into the
document.

> =A0 =A0M2PA 3) RFC 4165: 4.1.5: Flow Control
>
> =A0 =A0When the peer M2PA receives the first Link Status Busy message,= it
> =A0 =A0SHALL start the Remote Congestion timer T6 if there are message= s in the
> =A0 =A0retransmission buffer awaiting acknowledgement (i.e., T7 is run= ning).
> =A0 =A0M2PA SHALL stop the T7 timer if it is running. =A0Additional Li= nk Status
> =A0 =A0Busy messages received while T6 is running do not cause T6 to b= e reset
> =A0 =A0and do not cause T7 to be started. =A0While T6 is running, T7 S= HALL NOT
> =A0 =A0be started. When the peer M2PA receives the Link Status Busy En= ded
> =A0 =A0message and T6 has not expired, it SHALL stop T6 (if T6 is runn= ing) and
> =A0 =A0start T7 (if there are messages awaiting acknowledgement in the=
> =A0 =A0retransmission buffer).

Is there a question in there?

> =A0 =A0M2PA 4) Do you recall in RFC 4165 (or any other RFC) a referenc= e to SSN
> =A0 =A0being used as a parameter for =A0"Changeover" with mo= st significant 8
> =A0 =A0bits being set to zero? Is there a relation between FSN / BSN o= f M2PA
> =A0 =A0and TSN / SSN of SCTP?

Only 24-bits are significant because the XCO/XCA can only accept 24 bits. =A0There is no relationship between FSN/BSN and TSN/SSN.

> =A0 =A0M2UA:
> =A0 =A0M2UA 1) While using M2UA, is there a restriction that on SS7 si= de of an
> =A0 =A0SG, there can be only "one type" of node (say, PSTN C= lassical Switch)
> =A0 =A0and on IP side of THAT SG, there can be only "one type&quo= t; of node (say,
> =A0 =A0MGC)? In one of tutorials (ZYTRAX), we have come across an expr= ession
> =A0 =A0that says: "The whole IP network is represented by a singl= e point code
> =A0 =A0that addresses the MGC at the network edge. Therefore all messa= ges from
> =A0 =A0the SS7 side going to the IP side are sent to the MGC through t= he SG.
> =A0 =A0Do you agree with this statement? If yes, is that UNCONDITIONAL= or this
> =A0 =A0statement is true only under certain environment (like M2UA)?? = Is
> =A0 =A0ZYTRAX, for example, making this statement only for a certain s= cenario
> =A0 =A0- where M2UA is deployed for connecting up (say) PSTN SS7 node = with
> =A0 =A0MGC?

M2UA has no IPSP mode, just ASP/SG mode. =A0M2PA is used where you wo= uld
want to use M2UA for IPSP.

Aditi: Can you tell us the diffe= rence between IPSP and ASP?=A0

> =A0 =A0M2UA 2) While using M2UA, is there a restriction that on SS7 si= de of an
> =A0 =A0SG, there can be only "one type" of node (say, PSTN C= lassical Switch)
> =A0 =A0and on IP side of THAT SG, there can be only "one type&quo= t; of

Same as above.

> =A0 =A0M2UA 3) In the RFC, it is stated that the M2UA SPECIFIC HEADER = is
> =A0 =A0present IF AT ALL only for MAUP Message Class; however, it goes= on to
> =A0 =A0say that it may or may NOT be present in even when the message = is an
> =A0 =A0MAUP (MTP-2 User Adaptation Messages / Protocol??) messages. Th= us,
> =A0 =A0after Common Header, DIRECTLY, parameters may follow in T-L-V f= ormat.
>
> =A0 =A0(i) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Is it prescribed as to W= HEN this can be (should
> =A0 =A0be) absent, & when not - - e.g. does Message Type automatic= ally give
> =A0 =A0any clue for this??

It is detailed in the message format of each message in the RFC.

> =A0 =A0(ii) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0How does the RECEIVING ENTI= TY come to know whether
> =A0 =A0the M2UA specific header is present or not - - -is it by lookin= g at the
> =A0 =A0TWO BYTES that follow "end of COMMON HEADER (message lengt= h)", & if the
> =A0 =A0value therein is "01 (Hex) - indicating Integar Value for = IId", THEN
> =A0 =A0CONCLUDE that the (M2UA specific) header is present & IF IT= IS ANYTHING
> =A0 =A0OTHER THAN 01H (or, of course, 03H for ANSI Networks), then TRY= TO
> =A0 =A0INTERPRET the same as a "Parameter Tag"??

The header is not optional: it is included in some message types and = not
in others. =A0The message type determines whether the header must be there<= br> or not.

> =A0 =A0M2UA 3) In one of the (SS7 with INTRO to SIGTRAN) training sess= ions
> =A0 =A0that we held last month, one of the trainees informed us that t= hey have
> =A0 =A0deployed M2UA in the sense that they have a CLUSTER OF BLADE SE= RVERS in
> =A0 =A0their MGC. All those blades are represented by a SINGLE SIGNALL= ING
> =A0 =A0POINT CODE, but EACH has a unique GT. The M2UA is used INTERNAL= LY
> =A0 =A0between the SS7 front end (the master server- so to say), &= the
> =A0 =A0back-end cluster of Blade Servers. Is this a typical usage that= you
> =A0 =A0have seen too (we ask this because it is usually very rare to S= EE / get
> =A0 =A0an example of, an M2UA deployment !!)?

M2UA served a purpose for legacy arrangements that is not so prevalen= t
any more. =A0Nevertheless, ETSI/3GPP proscribes is use in a number of
scenarios.

> =A0 =A0M3UA:
>
> =A0 =A0M3UA 1) Section 1.1, Terminologies, states Where an SG contains= more
> =A0 =A0than one SGP, the SG is a logical entity, and the contained SGP= s are
> =A0 =A0assumed to be coordinated into a single management view to the = SS7
> =A0 =A0network and to the supported Application Servers. =A0We are con= fused
> =A0 =A0about what the underlined part means.

An SG has a point code, regardless of the number of SGPs providing identical access to the SS7 network through that point code. =A0Remember that a point code is an MTP-Level3-Entity-Identifier in the SS7 network.

> =A0 =A0M3UA 2) RFC also states that An IPSP is essentially the same as= an ASP,
> =A0 =A0except that it uses M3UA in a point-to-point fashion. What does=
> =A0 =A0point-to-point mean?

One IPSP is at one MTP end-point, the other is at the other MTP
end-point. =A0There is no relay point (STP), or other MTP entity between them. =A0They are used in this point-to-point fashion.

> =A0 =A0M3UA 3) Routing Context is a 4 byte number having a one-to-one<= br> > =A0 =A0relationship with Routing Key. Moreover, Routing context is als= o
> =A0 =A0transmitted from 1 node to the other as part of the message. Is= it
> =A0 =A0correct to interpret that Routing Context is something similar = to
> =A0 =A0Translation Type use in SCCP meaning possibly that the receivin= g node
> =A0 =A0indexes a (specific / desired) table basis the received RC valu= e, &
> =A0 =A0LOOKS for Routing Key within that table?

It has no relation to TT. =A0It is closer to the concept of a combine= d
routeset under MTP.

--brian


--
Brian F. G. Bidulock
bidulock@openss7.= org
http://www.openss7.or= g/

--00151773db9a0379ce04aa9c183b-- From bidulock@openss7.org Tue Aug 16 03:19:08 2011 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C8921F8AE1 for ; Tue, 16 Aug 2011 03:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89GumJy0Qz8w for ; Tue, 16 Aug 2011 03:19:07 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.117.178]) by ietfa.amsl.com (Postfix) with ESMTP id 25B3521F8ACE for ; Tue, 16 Aug 2011 03:19:07 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p7GAJoQc026169; Tue, 16 Aug 2011 04:19:50 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p7GAJoQh031758; Tue, 16 Aug 2011 04:19:50 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p7GAJo1d031757; Tue, 16 Aug 2011 04:19:50 -0600 Date: Tue, 16 Aug 2011 04:19:50 -0600 From: "Brian F. G. Bidulock" To: aditi someshwar Message-ID: <20110816101950.GA30975@openss7.org> Mail-Followup-To: aditi someshwar , sigtran@ietf.org References: <20110808215439.GB15848@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sigtran@ietf.org Subject: Re: [Sigtran] SIGTRAN specs: Some doubts X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 10:19:08 -0000 Aditi, aditi someshwar wrote: (Tue, 16 Aug 2011 15:05:01) > > > C. - - - >>>> When TSN = 241 is sent (at 14:01 hrs / 09 Aug 2011), > TIMER T shall be RESET (so now it will "blow the whistle at 15:01 hrs, > rather than at 15;00 hrs IF IT HAD NOT BEEN RESET). Have you ever read the specification? If so, reread the paragraph at the bottom of page 77. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From supreet_jain@yahoo.com Wed Aug 24 06:27:30 2011 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111C421F8B36 for ; Wed, 24 Aug 2011 06:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[BAYES_60=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgVEU0DVII1u for ; Wed, 24 Aug 2011 06:27:29 -0700 (PDT) Received: from nm20.bullet.mail.ac4.yahoo.com (nm20.bullet.mail.ac4.yahoo.com [98.139.52.217]) by ietfa.amsl.com (Postfix) with SMTP id 6E19D21F889A for ; Wed, 24 Aug 2011 06:27:29 -0700 (PDT) Received: from [98.139.52.193] by nm20.bullet.mail.ac4.yahoo.com with NNFMP; 24 Aug 2011 13:28:37 -0000 Received: from [98.139.52.159] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 24 Aug 2011 13:28:37 -0000 Received: from [127.0.0.1] by omp1042.mail.ac4.yahoo.com with NNFMP; 24 Aug 2011 13:28:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 255110.89096.bm@omp1042.mail.ac4.yahoo.com Received: (qmail 73744 invoked by uid 60001); 24 Aug 2011 13:28:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1314192517; bh=Vo8l35tb4UXk9enCR1qMB/zcexWJ0ul8oByUqyiX5iM=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=Ub7ECFREhFDZO3UArv+YgQil/l5UsL1JXd2QcMUdmb7khgbDuYTxD1ltXV2QgNkDZzEVL4xMAVgR1ZsK7KZKT7mT8m7sP88w051lV/7kq0flwnsE5RgaLs+Eqg7rCmgKV+qHqgDwUGf9ZAgCnQD3NB/zuu9Y7OQyeMxC1G0yQK8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=tXbp4qwdYXLTZLS63U7KSt9zyXitBIrKlc7HutCqPd41xDuyYYnmkwAoV8KKotZjpYrvYsmUN2gxj8YgWOX5QcdrALRDerjBz8x9p2PhjmihOlDR0IKxF+SUucwEkAp2KaE3LXyR9/YK6MMlcYUTEXDLAxhq8xsdU6tppLI8/qY=; X-YMail-OSG: _cJ7pI8VM1kawHA4.6TVHmW7EqvGctS_jgCaZpMZTn83ulb tJ9jbImAfxRheIHLUC46E6z2N9hYf0lOGwbWefxsQ1mB4CdTxYWMVraidGu9 h.cT5wc.vPx9fj.kfYZu0Zx11lZFu7EKKN2akvdFjFzQkz_xkVejtS_BZm0S Th1JMFG5LgmKt_VDw3a6zfzD8v2pRx4p88cVivpmi4nqobHDbMND5mOrOu2I sHXcplXFWeFVasqTmihMcdHJJZrjA534V0MdWXAV0m1rQHlEQNSkMAiqtHE2 RXbPzxa1PTonkXRnLVSU_1LSAukWTr2L0rHYCyHMDXfO4td4ryiSLlvZfYhq 2kyNlNkD4VAGmoDSwkdtwVZL0IRKVGlreKK9L90sQ8pNzbKxqCByBEajaGxD VCYEH7AZNFMxU5Gx_c24- Received: from [121.241.96.5] by web59606.mail.ac4.yahoo.com via HTTP; Wed, 24 Aug 2011 06:28:37 PDT X-Mailer: YahooMailWebService/0.8.113.315625 Message-ID: <1314192517.55007.YahooMailNeo@web59606.mail.ac4.yahoo.com> Date: Wed, 24 Aug 2011 06:28:37 -0700 (PDT) From: Supreet Jain To: "sigtran@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1902482079-1314192517=:55007" Subject: [Sigtran] Interface Identifier in ASPTM message in M2UA X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Supreet Jain List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 04:31:23 -0000 --0-1902482079-1314192517=:55007 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello all, =0A=A0=0AAccording to RFC 3331 section 3.2, "The M2UA specific m= essage header will immediately follow the common message header, but will o= nly be used with MAUP messages." Here, it is also mentioned that "Interface= Identifier=A0Length=A0is always set to 8". =0AAlso, in section 3.3.2.7, Li= st of Interface Identifiers=A0in ASP Active message=A0is identified by sing= le=A0Tag (0x1=3Dinteger) followed by length and List of Interface Identifie= rs.=0AMy query is: =0A1. Can the length=A0be more than 8 for Tag (0x1=3Dint= eger) in ASPTM messages=A0as it is not=A0a MAUP message?=0A2. If not, why?= =A0=0A=A0=0ARegards,=0ASupreet --0-1902482079-1314192517=:55007 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all,
 
According to RFC 3331 section 3.2, "The M2UA specific message header will immedia= tely follow the common message header, but will only be used with MAUP messages." Here, it is also mentioned= that "Interface Identifier Length is always set to 8".
Also, in section 3.3.2.7, List of Interface Iden= tifiers in ASP Active message is identified by single Tag (0= x1=3Dinteger) followed by length and List of Interface Identifiers.
My query is:
1. Can the length be more than 8 for Tag (0= x1=3Dinteger) in ASPTM messages&n= bsp;as it is not a MAUP mess= age?
2. If not, why? 
 
Regards,
Supreet
 
 
 
 
--0-1902482079-1314192517=:55007-- From aditi.someshwar@gmail.com Wed Aug 24 23:38:21 2011 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A2021F8AA9 for ; Wed, 24 Aug 2011 23:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UKvfGvEKYSz for ; Wed, 24 Aug 2011 23:38:21 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id F042A21F8A80 for ; Wed, 24 Aug 2011 23:38:19 -0700 (PDT) Received: by yxj17 with SMTP id 17so1749098yxj.31 for ; Wed, 24 Aug 2011 23:39:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VFKHTIiMELPgDAMv7n+Z3ciJgGs8HKwqSrcU99AXg7Q=; b=SZkb0gyDJlSVIZjY5Gk68bcCCXZBfaxbPV/K+9O7a6Wm3S8+POe6rVl1rlX2yc/LzY 79twDys/VIx6bMzuh0uNKpV8MEps66n2BzPXxOlaTQgcKqUd7WJXUVifzXZR/Bo6fMLw 8lgZokujQGBKnnDr9KLaX8QOsQaS5GVoFQXv4= MIME-Version: 1.0 Received: by 10.231.83.130 with SMTP id f2mr12216023ibl.15.1314254372196; Wed, 24 Aug 2011 23:39:32 -0700 (PDT) Received: by 10.231.15.140 with HTTP; Wed, 24 Aug 2011 23:39:31 -0700 (PDT) In-Reply-To: <1314192517.55007.YahooMailNeo@web59606.mail.ac4.yahoo.com> References: <1314192517.55007.YahooMailNeo@web59606.mail.ac4.yahoo.com> Date: Thu, 25 Aug 2011 12:09:31 +0530 Message-ID: From: aditi someshwar To: Supreet Jain Content-Type: multipart/alternative; boundary=000e0cd535a2ffd0d004ab4eb03e Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] Interface Identifier in ASPTM message in M2UA X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 06:38:21 -0000 --000e0cd535a2ffd0d004ab4eb03e Content-Type: text/plain; charset=ISO-8859-1 Hi Supreet, As per the structure of ASPAC defined under the section 3.3.2.7, the Interface Identifier (Tag 0x1), the value can be a set of "Interface Identifiers". The length can be other than 8. Thanks and Regards, Aditi On Wed, Aug 24, 2011 at 6:58 PM, Supreet Jain wrote: > Hello all, > > According to RFC 3331 section 3.2, "The M2UA specific message header will > immediately follow the common message header, but will only be used with > MAUP messages." Here, it is also mentioned that "Interface > Identifier Length is always set to 8". > Also, in section 3.3.2.7, List of Interface Identifiers in ASP Active > message is identified by single Tag (0x1=integer) followed by length and > List of Interface Identifiers. > My query is: > 1. Can the length be more than 8 for Tag (0x1=integer) in ASPTMmessages as it is not a > MAUP message? > 2. If not, why? > > Regards, > Supreet > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > > --000e0cd535a2ffd0d004ab4eb03e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Supreet,

As per the structur= e of ASPAC defined under the section 3.3.2.7, the Interface Identifier (Tag= 0x1), the value can be a set of "Interface Identifiers". The len= gth can be other than 8.
Thanks and Regards,
Aditi

On Wed, Aug 24, 2011 at 6:58 PM, Supreet Jai= n <supreet_j= ain@yahoo.com> wrote:
Hello all,
=A0
According to RFC 3331 section 3.2, "The M2UA specifi= c message header will immediately follow the common message header, but wil= l only be used with MAUP messages." Here, it is also ment= ioned that "Interface Identifier=A0Length=A0is always set to 8". =
Also, in section 3.3.2.7, List of Interface Identifiers=A0in ASP Activ= e message=A0is identified by single=A0Tag (0x1=3Dinteger) followed by lengt= h and List of Interface Identifiers.
My query is:
1. Can the length=A0be more than 8 for Tag (0x1=3Dinteger) in AS= PTM messages=A0as it is not=A0a MAUP message?
2. If not, why?=A0
=A0
Regards,
Supreet
=A0
=A0
=A0
=A0

_____________________________________________= __
Sigtran mailing list
Sigtran@ietf.org
https://www.ietf.org/mailman/listinfo/sigtran


--000e0cd535a2ffd0d004ab4eb03e-- From rajesh.makhija@aricent.com Mon Aug 29 04:21:08 2011 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A74021F856B for ; Mon, 29 Aug 2011 04:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFR84c7TVhPI for ; Mon, 29 Aug 2011 04:21:07 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 71C7921F84E1 for ; Mon, 29 Aug 2011 04:21:06 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 9D3F036B29; Mon, 29 Aug 2011 16:47:02 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id 86F9D36BDA; Mon, 29 Aug 2011 16:47:02 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Mon, 29 Aug 2011 16:52:23 +0530 From: Rajesh Makhija To: "sigtran@ietf.org" Date: Mon, 29 Aug 2011 16:52:32 +0530 Thread-Topic: Re: [Sigtran] Interface Identifier in ASPTM message in M2UA Thread-Index: AcxmPfHGC6L7SqdQRfCxEYSuPFTqFw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_ED87E3B738CE6240A27EC10A62BE60AE28C74B9650GUREXMB01ASIA_" MIME-Version: 1.0 Cc: "supreet_jain@yahoo.com" Subject: Re: [Sigtran] Interface Identifier in ASPTM message in M2UA X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 11:21:08 -0000 --_000_ED87E3B738CE6240A27EC10A62BE60AE28C74B9650GUREXMB01ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Aditi Thanks for your inputs. With reference to your last mail: "As per the structure of ASPAC defined under the section 3.3.2.7, the Inter= face Identifier (Tag 0x1), the value can be a set of "Interface Identifiers= ". The length can be other than 8." However from one of the earlier discussion threads on Sigtran forum....: www.ietf.org/mail-archive/web/sigtran/current/msg08554.html It appears that if multiple interface identifiers are to be sent they must = be sent in the following manner....snippet from earlier discussions follows= : "If you want to list two Integer Interface Identifiers it is: Tag (0x1), Length (8) Integer interface id 1 Tag (0x1), Length (8) Integer interface id 2 Therefore, from the earlier discussion thread, it appears that the length f= ield can only be 8. This is slightly different from what you mentioned. If= possible, I would request Brian to throw more light on this matter. It would be great if we can reach a consensus on this matter on this forum = (.i.e. length can only be 8 or not more than 8 is also possible when tag is= (0x1), as this can possibly lead to interoperability issues. Thank you in advance for your views on this matter. Thanks and Regards Rajesh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D --_000_ED87E3B738CE6240A27EC10A62BE60AE28C74B9650GUREXMB01ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Aditi

 

Thanks for your inputs.

 

With reference to your last mail:

 

“As per the structure of ASPAC defined under the s= ection 3.3.2.7, the Interface Identifier (Tag 0x1), the value can be a set = of "Interface Identifiers". The length can be other than 8.“

 

However from one of the earlier discussion threads on Si= gtran forum….:

 

www.ietf.org/mail-archive/web/sigtran/current/msg08554.html=

 

It appears that if multiple interface identifiers are to= be sent they must be sent in the following manner….snippet from earl= ier discussions follows:

 

“If you want to list two Integer Interface Identif= iers it is:

 

         &n= bsp;  Tag (0x1), Length (8)

         &n= bsp;  Integer interface id 1

         &n= bsp;  Tag (0x1), Length (8)

         &n= bsp;  Integer interface id 2

 

Therefore, from the earlier discussion thread, it appear= s that the length field can only be 8.  This is slightly different fro= m what you mentioned. If possible, I would request Brian to throw more light on this matter.

 

It would be great if we can reach a consensus on this ma= tter on this forum (.i.e. length can only be 8 or not more than 8 is also p= ossible when tag is (0x1), as this can possibly lead to interoperability issues.

 

Thank you in advance for your views on this matter.=

 

Thanks and Regards

 

Rajesh

 

 

 

 

 





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
--_000_ED87E3B738CE6240A27EC10A62BE60AE28C74B9650GUREXMB01ASIA_-- From rajesh.makhija@aricent.com Mon Aug 29 04:27:35 2011 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0DD21F85F2 for ; Mon, 29 Aug 2011 04:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VN2n6G3SyoQ7 for ; Mon, 29 Aug 2011 04:27:34 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by ietfa.amsl.com (Postfix) with ESMTP id D23DA21F8B11 for ; Mon, 29 Aug 2011 04:27:33 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 4D8D336C24; Mon, 29 Aug 2011 16:53:34 +0530 (IST) Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (Postfix) with ESMTP id 3500D36C23; Mon, 29 Aug 2011 16:53:34 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Mon, 29 Aug 2011 16:58:56 +0530 From: Rajesh Makhija To: "sigtran@ietf.org" , "sigtran@ietfa.amsl.com" Date: Mon, 29 Aug 2011 16:59:05 +0530 Thread-Topic: [Sigtran] Interface Identifier in ASPTM message in M2UA Thread-Index: AcxmPfHGC6L7SqdQRfCxEYSuPFTqFwAAM+Ew Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_ED87E3B738CE6240A27EC10A62BE60AE28C74B9656GUREXMB01ASIA_" MIME-Version: 1.0 Cc: "supreet_jain@yahoo.com" Subject: Re: [Sigtran] Interface Identifier in ASPTM message in M2UA X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 11:27:36 -0000 --_000_ED87E3B738CE6240A27EC10A62BE60AE28C74B9656GUREXMB01ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Aditi Thanks for your inputs. With reference to your last mail: "As per the structure of ASPAC defined under the section 3.3.2.7, the Inter= face Identifier (Tag 0x1), the value can be a set of "Interface Identifiers= ". The length can be other than 8." However from one of the earlier discussion threads on Sigtran forum....: www.ietf.org/mail-archive/web/sigtran/current/msg08554.html It appears that if multiple interface identifiers are to be sent they must = be sent in the following manner....snippet from earlier discussions follows= : "If you want to list two Integer Interface Identifiers it is: Tag (0x1), Length (8) Integer interface id 1 Tag (0x1), Length (8) Integer interface id 2 Therefore, from the earlier discussion thread, it appears that the length f= ield can only be 8. This is slightly different from what you mentioned. If= possible, I would request Brian to throw more light on this matter. It would be great if we can reach a consensus on this matter on this forum = (.i.e. length can only be 8 or not more than 8 is also possible when tag is= (0x1), as this can possibly lead to interoperability issues. Thank you in advance for your views on this matter. Thanks and Regards Rajesh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D --_000_ED87E3B738CE6240A27EC10A62BE60AE28C74B9656GUREXMB01ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Aditi

 

Thanks for your inputs.

 

With reference to your last mail:

 

“As per the structure of ASPAC defined under the s= ection 3.3.2.7, the Interface Identifier (Tag 0x1), the value can be a set = of "Interface Identifiers". The length can be other than 8.“

 

However from one of the earlier discussion threads on Si= gtran forum….:

 

www.ietf.org/mail-archive/web/sigtran/current/msg08554.html=

 

It appears that if multiple interface identifiers are to= be sent they must be sent in the following manner….snippet from earl= ier discussions follows:

 

“If you want to list two Integer Interface Identif= iers it is:

 

         &n= bsp;  Tag (0x1), Length (8)

         &n= bsp;  Integer interface id 1

         &n= bsp;  Tag (0x1), Length (8)

         &n= bsp;  Integer interface id 2

 

Therefore, from the earlier discussion thread, it appear= s that the length field can only be 8.  This is slightly different fro= m what you mentioned. If possible, I would request Brian to throw more light on this matter.

 

It would be great if we can reach a consensus on this ma= tter on this forum (.i.e. length can only be 8 or not more than 8 is also p= ossible when tag is (0x1), as this can possibly lead to interoperability issues.

 

Thank you in advance for your views on this matter.=

 

Thanks and Regards

 

Rajesh

 

 

 

 

 





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
--_000_ED87E3B738CE6240A27EC10A62BE60AE28C74B9656GUREXMB01ASIA_-- From rajesh.makhija@aricent.com Mon Aug 29 04:27:35 2011 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAD121F8B17 for ; Mon, 29 Aug 2011 04:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xZiZN6DRDH8 for ; Mon, 29 Aug 2011 04:27:34 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE7821F8B0E for ; Mon, 29 Aug 2011 04:27:33 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 4D8D336C24; Mon, 29 Aug 2011 16:53:34 +0530 (IST) Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (Postfix) with ESMTP id 3500D36C23; Mon, 29 Aug 2011 16:53:34 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Mon, 29 Aug 2011 16:58:56 +0530 From: Rajesh Makhija To: "sigtran@ietf.org" , "sigtran@ietfa.amsl.com" Date: Mon, 29 Aug 2011 16:59:05 +0530 Thread-Topic: [Sigtran] Interface Identifier in ASPTM message in M2UA Thread-Index: AcxmPfHGC6L7SqdQRfCxEYSuPFTqFwAAM+Ew Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_ED87E3B738CE6240A27EC10A62BE60AE28C74B9656GUREXMB01ASIA_" MIME-Version: 1.0 Cc: "supreet_jain@yahoo.com" Subject: Re: [Sigtran] Interface Identifier in ASPTM message in M2UA X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 11:27:36 -0000 --_000_ED87E3B738CE6240A27EC10A62BE60AE28C74B9656GUREXMB01ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Aditi Thanks for your inputs. With reference to your last mail: "As per the structure of ASPAC defined under the section 3.3.2.7, the Inter= face Identifier (Tag 0x1), the value can be a set of "Interface Identifiers= ". The length can be other than 8." However from one of the earlier discussion threads on Sigtran forum....: www.ietf.org/mail-archive/web/sigtran/current/msg08554.html It appears that if multiple interface identifiers are to be sent they must = be sent in the following manner....snippet from earlier discussions follows= : "If you want to list two Integer Interface Identifiers it is: Tag (0x1), Length (8) Integer interface id 1 Tag (0x1), Length (8) Integer interface id 2 Therefore, from the earlier discussion thread, it appears that the length f= ield can only be 8. This is slightly different from what you mentioned. If= possible, I would request Brian to throw more light on this matter. It would be great if we can reach a consensus on this matter on this forum = (.i.e. length can only be 8 or not more than 8 is also possible when tag is= (0x1), as this can possibly lead to interoperability issues. Thank you in advance for your views on this matter. Thanks and Regards Rajesh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D --_000_ED87E3B738CE6240A27EC10A62BE60AE28C74B9656GUREXMB01ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Aditi

 

Thanks for your inputs.

 

With reference to your last mail:

 

“As per the structure of ASPAC defined under the s= ection 3.3.2.7, the Interface Identifier (Tag 0x1), the value can be a set = of "Interface Identifiers". The length can be other than 8.“

 

However from one of the earlier discussion threads on Si= gtran forum….:

 

www.ietf.org/mail-archive/web/sigtran/current/msg08554.html=

 

It appears that if multiple interface identifiers are to= be sent they must be sent in the following manner….snippet from earl= ier discussions follows:

 

“If you want to list two Integer Interface Identif= iers it is:

 

         &n= bsp;  Tag (0x1), Length (8)

         &n= bsp;  Integer interface id 1

         &n= bsp;  Tag (0x1), Length (8)

         &n= bsp;  Integer interface id 2

 

Therefore, from the earlier discussion thread, it appear= s that the length field can only be 8.  This is slightly different fro= m what you mentioned. If possible, I would request Brian to throw more light on this matter.

 

It would be great if we can reach a consensus on this ma= tter on this forum (.i.e. length can only be 8 or not more than 8 is also p= ossible when tag is (0x1), as this can possibly lead to interoperability issues.

 

Thank you in advance for your views on this matter.=

 

Thanks and Regards

 

Rajesh

 

 

 

 

 





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
--_000_ED87E3B738CE6240A27EC10A62BE60AE28C74B9656GUREXMB01ASIA_-- From bidulock@openss7.org Mon Aug 29 20:18:00 2011 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A1521F85AC for ; Mon, 29 Aug 2011 20:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8EP2aPvES5H for ; Mon, 29 Aug 2011 20:17:59 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.117.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2E30221F8568 for ; Mon, 29 Aug 2011 20:17:58 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p7U3I0IO023672; Mon, 29 Aug 2011 21:18:00 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p7U3HxF5023084; Mon, 29 Aug 2011 21:17:59 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p7U3Huvt023082; Mon, 29 Aug 2011 21:17:56 -0600 Date: Mon, 29 Aug 2011 21:17:56 -0600 From: "Brian F. G. Bidulock" To: Rajesh Makhija Message-ID: <20110830031756.GA20669@openss7.org> Mail-Followup-To: Rajesh Makhija , "sigtran@ietf.org" , "sigtran@ietfa.amsl.com" , "supreet_jain@yahoo.com" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "sigtran@ietfa.amsl.com" , "supreet_jain@yahoo.com" , "sigtran@ietf.org" Subject: Re: [Sigtran] Interface Identifier in ASPTM message in M2UA X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 03:18:00 -0000 Rajesh, Read RFC 3331/Page 22: The Tag value for the Integer-based Interface Identifier is 0x1. The length is always set to a value of 8. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From bidulock@openss7.org Mon Aug 29 20:22:55 2011 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F3121F8663 for ; Mon, 29 Aug 2011 20:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU688-8M+lL6 for ; Mon, 29 Aug 2011 20:22:55 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.117.178]) by ietfa.amsl.com (Postfix) with ESMTP id 271E121F863E for ; Mon, 29 Aug 2011 20:22:55 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p7U3I0IO023672; Mon, 29 Aug 2011 21:18:00 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p7U3HxF5023084; Mon, 29 Aug 2011 21:17:59 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p7U3Huvt023082; Mon, 29 Aug 2011 21:17:56 -0600 Date: Mon, 29 Aug 2011 21:17:56 -0600 From: "Brian F. G. Bidulock" To: Rajesh Makhija Message-ID: <20110830031756.GA20669@openss7.org> Mail-Followup-To: Rajesh Makhija , "sigtran@ietf.org" , "sigtran@ietfa.amsl.com" , "supreet_jain@yahoo.com" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "sigtran@ietfa.amsl.com" , "supreet_jain@yahoo.com" , "sigtran@ietf.org" Subject: Re: [Sigtran] Interface Identifier in ASPTM message in M2UA X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 03:22:55 -0000 Rajesh, Read RFC 3331/Page 22: The Tag value for the Integer-based Interface Identifier is 0x1. The length is always set to a value of 8. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From supreet_jain@yahoo.com Tue Aug 30 03:23:33 2011 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F148D21F8C06 for ; Tue, 30 Aug 2011 03:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nNng-QTPeXm for ; Tue, 30 Aug 2011 03:23:32 -0700 (PDT) Received: from nm9.bullet.mail.ac4.yahoo.com (nm9.bullet.mail.ac4.yahoo.com [98.139.52.206]) by ietfa.amsl.com (Postfix) with SMTP id A2E6021F8C04 for ; Tue, 30 Aug 2011 03:23:31 -0700 (PDT) Received: from [98.139.52.191] by nm9.bullet.mail.ac4.yahoo.com with NNFMP; 30 Aug 2011 10:24:16 -0000 Received: from [98.139.52.172] by tm4.bullet.mail.ac4.yahoo.com with NNFMP; 30 Aug 2011 10:24:16 -0000 Received: from [127.0.0.1] by omp1055.mail.ac4.yahoo.com with NNFMP; 30 Aug 2011 10:24:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 138748.98324.bm@omp1055.mail.ac4.yahoo.com Received: (qmail 37767 invoked by uid 60001); 30 Aug 2011 10:24:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1314699855; bh=YZ33w3kqXEwJKqjm6AStOwKCLw5cWqJJtvNlfzIdm48=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nZ3Iiq/jn0AKzqX0poMYR+uzVRy6SzYAyG4nd7PRQj8a5U4PQraqNqmCp5vD771z8SXB+JicKazXHtPQ00djKkOroJ3sNwWsproazOm73XYyNsStkzrdV0yJT4H+EvRClE7eDvE9neth7ygAVFgnRtvnHbQosq9tSmeMJUgByvQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=IvFAc/u0Fk4DBevtwOV2WY/JVKUOZjdLroMgyYQuo5xCw/LLHTDESKE6pqm6MM2BY9gduoCCnIws6/FMjR4oxL/ud7zaaH6E5b4AYIdCgMBXmiipTNyPd7x759uoM4plNZ8NmuuOqkW+n+FhB3GbWYDI6+xHh3UF6u7HHAZijEA=; X-YMail-OSG: aHOUEvAVM1nEqfvc6u_gDnwRilxBcnyMv0mjbq9RKr_r1Mv C1CMoS9ZjHkIkFGksiADHdVEv3oaQd7CIObWmzzOpIrapQh.7.M3ILbnFsx8 kHsBjfhZoQxIurHFEP2nfEEFAKFPveUeBmq6g_h6V52OiL4wqBt0fsk4S0xU EE4CWuoRo_Vk.OA2qYNNNohxPHeFUx9V9MMwTPKp8FDa71y7LEvrdRwQwzq7 ddVKVGNBEF9eQEQm2nB.vLpVaHXuYeIt6rRriyBMzjH7fJMolpJBWgwOX9ek a.3pkD_BkhT0QUSH8LRG_Cq3VDxylL3CPkN4R5rxDQLNAv1Ph9S_.jBcApkh jgxYQHM3K7v7XxwQP.Sx88.u4J161IroYgc3ZkT9fh8grYeM6pZ6RSJ7_yYy K6YqxdNRnmB8P46HARIQb4Rz5CdOOemhZWUUY2Wr.dG_Jt4Q- Received: from [61.247.254.226] by web59611.mail.ac4.yahoo.com via HTTP; Tue, 30 Aug 2011 03:24:15 PDT X-Mailer: YahooMailWebService/0.8.113.315625 References: <20110830031756.GA20669@openss7.org> Message-ID: <1314699855.37564.YahooMailNeo@web59611.mail.ac4.yahoo.com> Date: Tue, 30 Aug 2011 03:24:15 -0700 (PDT) From: Supreet Jain To: "bidulock@openss7.org" In-Reply-To: <20110830031756.GA20669@openss7.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1205768417-1314699855=:37564" Cc: "sigtran@ietfa.amsl.com" , "sigtran@ietf.org" Subject: Re: [Sigtran] Interface Identifier in ASPTM message in M2UA X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Supreet Jain List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 10:23:33 -0000 --0-1205768417-1314699855=:37564 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Brain,=0A=C2=A0=0AThank you for giving insights on this matter. =C2=A0It= is now very clear that the length field should be equal to 8 for MAUP mess= ages. =0A=C2=A0=0AI would request you to throw some light for messages othe= r than MAUP (such as ASPAC). =0A=C2=A0=0ARFC 3331, section 3.2 states that:= =0A-----=0A=E2=80=9CThe Tag value for the Integer-based Interface Identifie= r is 0x1.=C2=A0 The =C2=A0length is always set to a value of 8.=E2=80=9D=0A= =C2=A0=0A=C2=A0=E2=80=9CThe M2UA specific message header will =C2=A0=C2=A0i= mmediately follow the common message header, but will =E2=80=9Conly=E2=80= =9D be used =C2=A0=C2=A0with =E2=80=9CMAUP=E2=80=9D messages.=E2=80=9D=0A--= --=0A=C2=A0=0AAs per RFC 3331, "The M2UA specific message header will=C2=A0= immediately follow the common message header, but will only be used=C2=A0wi= th MAUP messages".=0A=C2=A0=0AFor ASPTM (such as ASPAC) messages it is not = very clear on what should be the value of length field. =0A=C2=A0=0AAs per = RFC section 3.3.2.7, from the ASPAC message format it appears that multiple= interface identifiers values can be used along with a single tag (0x1)=E2= =80=A6.=0A=C2=A0=0A=C2=A0=0A=C2=A0=0A=C2=A0=C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2= 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Tag (0xb)=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Length =3D 8=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |=0A=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0Traffic Mode Type=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=0A=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=C2=A0=C2=A0 |=C2=A0=C2= =A0=C2=A0=C2=A0 Tag (0x1=3Dinteger)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Length=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=0A=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+=0A=C2=A0=C2=A0 /=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=0A=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Interface Identifiers*=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 /=0A=C2=A0=C2=A0 /=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=0A=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=C2=A0=0AIt would be great if you = could confirm if length can be greater than 8 for ASPAC messages or it has = to be always set to 8 for ASPAC as well.=0A=C2=A0=0AThank you in advance fo= r your views on this matter.=0A=C2=A0=0AThanks and Regards=0ASupreet Jain= =0A=C2=A0=0A=0AFrom: Brian F. G. Bidulock =0ATo: Raje= sh Makhija =0ACc: "sigtran@ietf.org" ; "sigtran@ietfa.amsl.com" ; "supreet_jain@= yahoo.com" =0ASent: Tuesday, August 30, 2011 8:47 A= M=0ASubject: Re: [Sigtran] Interface Identifier in ASPTM message in M2UA=0A= =0ARajesh,=0A=0ARead RFC 3331/Page 22:=0A=0A=C2=A0 The Tag value for the In= teger-based Interface Identifier is 0x1.=C2=A0 The=0A=C2=A0 length is alway= s set to a value of 8.=0A=0A--brian=0A=0A-- =0ABrian F. G. Bidulock=0Abidul= ock@openss7.org=0Ahttp://www.openss7.org/ --0-1205768417-1314699855=:37564 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Bra= in,
 
Thank you for giving insights on this matter.  It is now very clear that the length field should = be equal to 8 for MAUP messages.
 
I would request you to throw some light fo= r messages other than MAUP (such as= ASPAC).
 
RFC 3331, section 3.2 states that:<= /div>
-----
=E2=80=9CThe Tag value for the Integer-based Interface Identifier is= 0x1.  The  length is always set to a value of 8.=E2=80=9D=
 
 =E2=80=9CThe M2UA specific message header will   immediately follow the common m= essage header, but will =E2=80=9Conly=E2=80=9D be used   with =E2=80=9CMAUP=E2=80=9D messages.=E2=80=9D
----
 
As per RFC 3331, "The M2UA specific message header will immediately foll= ow the common message header, but will only be used with MAUP messages".
 
For ASPTM= (such as ASPAC) messages it= is not very clear on what should be the value of length field.
 
As per RFC section 3.3.2.7, from the ASPAC message format it appears that multiple interface identifier= s values can be used along with a single tag (0x1)=E2=80=A6.
 
 
 
<= SPAN style=3D"mso-spacerun: yes">   0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
<= SPAN style=3D"mso-spacerun: yes">   +-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<= SPAN style=3D"mso-spacerun: yes">   |           <= /SPAN>Tag (0xb)          = |     &n= bsp;      Length =3D 8         |
   +-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<= SPAN style=3D"mso-spacerun: yes">   |          &n= bsp;      = ;    Traffic Mode Type           &= nbsp;           &nbs= p; |
<= SPAN style=3D"mso-spacerun: yes">   +-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<= SPAN style=3D"mso-spacerun: yes">   |     Tag (0x1=3Dinteger)         |      =       Length            = |
<= SPAN style=3D"mso-spacerun: yes">   +-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<= SPAN style=3D"mso-spacerun: yes">   /          &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;  \
<= SPAN style=3D"mso-spacerun: yes">   \          &n= bsp;          Interface= Identifiers*    &nbs= p;            &= nbsp;  /
<= SPAN style=3D"mso-spacerun: yes">   /          &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;  \
<= SPAN style=3D"mso-spacerun: yes">   +-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
It would be great if you could confirm if = length can be greater than 8 for ASPAC messages or it has to be always set to 8 for ASPAC as well.
 
Thank you in = advance for your views on this matter.
 =
Thanks and Regards
Supreet Jain
 
<= /div>

From: Brian F. G. Bidulock <bidulock@openss7.org>
To: R= ajesh Makhija <rajesh.ma= khija@aricent.com>
Cc: "sigtran@ietf.org" <sigtran@ietf.org>; "sigtran@ietfa.amsl.com" <= ;sigtran@ietfa.amsl.com>; "supreet_jain@yahoo.com" <supreet_jain@yaho= o.com>
Sent: Tuesday,= August 30, 2011 8:47 AM
Subject: Re: [Sigtran] Interface Identifier in= ASPTM message in M2UA

Rajesh,

Read RFC 3331/Page 22:

  The Tag value= for the Integer-based Interface Identifier is 0x1.  The
  len= gth is always set to a value of 8.

--brian

--
Brian F. G. Bidulock
bidulock@openss7= .org
http://www.= openss7.org/


--0-1205768417-1314699855=:37564-- From supreet_jain@yahoo.com Tue Aug 30 03:23:33 2011 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E3821F8C04 for ; Tue, 30 Aug 2011 03:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.465 X-Spam-Level: X-Spam-Status: No, score=-1.465 tagged_above=-999 required=5 tests=[AWL=1.133, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k5pnon-3l0H for ; Tue, 30 Aug 2011 03:23:32 -0700 (PDT) Received: from nm7.bullet.mail.ac4.yahoo.com (nm7.bullet.mail.ac4.yahoo.com [98.139.52.204]) by ietfa.amsl.com (Postfix) with SMTP id 7C74D21F8BAA for ; Tue, 30 Aug 2011 03:23:32 -0700 (PDT) Received: from [98.139.52.190] by nm7.bullet.mail.ac4.yahoo.com with NNFMP; 30 Aug 2011 10:24:16 -0000 Received: from [98.139.52.138] by tm3.bullet.mail.ac4.yahoo.com with NNFMP; 30 Aug 2011 10:24:16 -0000 Received: from [127.0.0.1] by omp1021.mail.ac4.yahoo.com with NNFMP; 30 Aug 2011 10:24:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 100399.84526.bm@omp1021.mail.ac4.yahoo.com Received: (qmail 37767 invoked by uid 60001); 30 Aug 2011 10:24:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1314699855; bh=YZ33w3kqXEwJKqjm6AStOwKCLw5cWqJJtvNlfzIdm48=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nZ3Iiq/jn0AKzqX0poMYR+uzVRy6SzYAyG4nd7PRQj8a5U4PQraqNqmCp5vD771z8SXB+JicKazXHtPQ00djKkOroJ3sNwWsproazOm73XYyNsStkzrdV0yJT4H+EvRClE7eDvE9neth7ygAVFgnRtvnHbQosq9tSmeMJUgByvQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=IvFAc/u0Fk4DBevtwOV2WY/JVKUOZjdLroMgyYQuo5xCw/LLHTDESKE6pqm6MM2BY9gduoCCnIws6/FMjR4oxL/ud7zaaH6E5b4AYIdCgMBXmiipTNyPd7x759uoM4plNZ8NmuuOqkW+n+FhB3GbWYDI6+xHh3UF6u7HHAZijEA=; X-YMail-OSG: aHOUEvAVM1nEqfvc6u_gDnwRilxBcnyMv0mjbq9RKr_r1Mv C1CMoS9ZjHkIkFGksiADHdVEv3oaQd7CIObWmzzOpIrapQh.7.M3ILbnFsx8 kHsBjfhZoQxIurHFEP2nfEEFAKFPveUeBmq6g_h6V52OiL4wqBt0fsk4S0xU EE4CWuoRo_Vk.OA2qYNNNohxPHeFUx9V9MMwTPKp8FDa71y7LEvrdRwQwzq7 ddVKVGNBEF9eQEQm2nB.vLpVaHXuYeIt6rRriyBMzjH7fJMolpJBWgwOX9ek a.3pkD_BkhT0QUSH8LRG_Cq3VDxylL3CPkN4R5rxDQLNAv1Ph9S_.jBcApkh jgxYQHM3K7v7XxwQP.Sx88.u4J161IroYgc3ZkT9fh8grYeM6pZ6RSJ7_yYy K6YqxdNRnmB8P46HARIQb4Rz5CdOOemhZWUUY2Wr.dG_Jt4Q- Received: from [61.247.254.226] by web59611.mail.ac4.yahoo.com via HTTP; Tue, 30 Aug 2011 03:24:15 PDT X-Mailer: YahooMailWebService/0.8.113.315625 References: <20110830031756.GA20669@openss7.org> Message-ID: <1314699855.37564.YahooMailNeo@web59611.mail.ac4.yahoo.com> Date: Tue, 30 Aug 2011 03:24:15 -0700 (PDT) From: Supreet Jain To: "bidulock@openss7.org" In-Reply-To: <20110830031756.GA20669@openss7.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1205768417-1314699855=:37564" Cc: "sigtran@ietfa.amsl.com" , "sigtran@ietf.org" Subject: Re: [Sigtran] Interface Identifier in ASPTM message in M2UA X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Supreet Jain List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 10:23:33 -0000 --0-1205768417-1314699855=:37564 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Brain,=0A=C2=A0=0AThank you for giving insights on this matter. =C2=A0It= is now very clear that the length field should be equal to 8 for MAUP mess= ages. =0A=C2=A0=0AI would request you to throw some light for messages othe= r than MAUP (such as ASPAC). =0A=C2=A0=0ARFC 3331, section 3.2 states that:= =0A-----=0A=E2=80=9CThe Tag value for the Integer-based Interface Identifie= r is 0x1.=C2=A0 The =C2=A0length is always set to a value of 8.=E2=80=9D=0A= =C2=A0=0A=C2=A0=E2=80=9CThe M2UA specific message header will =C2=A0=C2=A0i= mmediately follow the common message header, but will =E2=80=9Conly=E2=80= =9D be used =C2=A0=C2=A0with =E2=80=9CMAUP=E2=80=9D messages.=E2=80=9D=0A--= --=0A=C2=A0=0AAs per RFC 3331, "The M2UA specific message header will=C2=A0= immediately follow the common message header, but will only be used=C2=A0wi= th MAUP messages".=0A=C2=A0=0AFor ASPTM (such as ASPAC) messages it is not = very clear on what should be the value of length field. =0A=C2=A0=0AAs per = RFC section 3.3.2.7, from the ASPAC message format it appears that multiple= interface identifiers values can be used along with a single tag (0x1)=E2= =80=A6.=0A=C2=A0=0A=C2=A0=0A=C2=A0=0A=C2=A0=C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2= 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Tag (0xb)=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Length =3D 8=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |=0A=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0Traffic Mode Type=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=0A=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=C2=A0=C2=A0 |=C2=A0=C2= =A0=C2=A0=C2=A0 Tag (0x1=3Dinteger)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Length=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=0A=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+=0A=C2=A0=C2=A0 /=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=0A=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Interface Identifiers*=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 /=0A=C2=A0=C2=A0 /=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=0A=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=C2=A0=0AIt would be great if you = could confirm if length can be greater than 8 for ASPAC messages or it has = to be always set to 8 for ASPAC as well.=0A=C2=A0=0AThank you in advance fo= r your views on this matter.=0A=C2=A0=0AThanks and Regards=0ASupreet Jain= =0A=C2=A0=0A=0AFrom: Brian F. G. Bidulock =0ATo: Raje= sh Makhija =0ACc: "sigtran@ietf.org" ; "sigtran@ietfa.amsl.com" ; "supreet_jain@= yahoo.com" =0ASent: Tuesday, August 30, 2011 8:47 A= M=0ASubject: Re: [Sigtran] Interface Identifier in ASPTM message in M2UA=0A= =0ARajesh,=0A=0ARead RFC 3331/Page 22:=0A=0A=C2=A0 The Tag value for the In= teger-based Interface Identifier is 0x1.=C2=A0 The=0A=C2=A0 length is alway= s set to a value of 8.=0A=0A--brian=0A=0A-- =0ABrian F. G. Bidulock=0Abidul= ock@openss7.org=0Ahttp://www.openss7.org/ --0-1205768417-1314699855=:37564 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Bra= in,
 
Thank you for giving insights on this matter.  It is now very clear that the length field should = be equal to 8 for MAUP messages.
 
I would request you to throw some light fo= r messages other than MAUP (such as= ASPAC).
 
RFC 3331, section 3.2 states that:<= /div>
-----
=E2=80=9CThe Tag value for the Integer-based Interface Identifier is= 0x1.  The  length is always set to a value of 8.=E2=80=9D=
 
 =E2=80=9CThe M2UA specific message header will   immediately follow the common m= essage header, but will =E2=80=9Conly=E2=80=9D be used   with =E2=80=9CMAUP=E2=80=9D messages.=E2=80=9D
----
 
As per RFC 3331, "The M2UA specific message header will immediately foll= ow the common message header, but will only be used with MAUP messages".
 
For ASPTM= (such as ASPAC) messages it= is not very clear on what should be the value of length field.
 
As per RFC section 3.3.2.7, from the ASPAC message format it appears that multiple interface identifier= s values can be used along with a single tag (0x1)=E2=80=A6.
 
 
 
<= SPAN style=3D"mso-spacerun: yes">   0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
<= SPAN style=3D"mso-spacerun: yes">   +-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<= SPAN style=3D"mso-spacerun: yes">   |           <= /SPAN>Tag (0xb)          = |     &n= bsp;      Length =3D 8         |
   +-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<= SPAN style=3D"mso-spacerun: yes">   |          &n= bsp;      = ;    Traffic Mode Type           &= nbsp;           &nbs= p; |
<= SPAN style=3D"mso-spacerun: yes">   +-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<= SPAN style=3D"mso-spacerun: yes">   |     Tag (0x1=3Dinteger)         |      =       Length            = |
<= SPAN style=3D"mso-spacerun: yes">   +-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<= SPAN style=3D"mso-spacerun: yes">   /          &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;  \
<= SPAN style=3D"mso-spacerun: yes">   \          &n= bsp;          Interface= Identifiers*    &nbs= p;            &= nbsp;  /
<= SPAN style=3D"mso-spacerun: yes">   /          &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;  \
<= SPAN style=3D"mso-spacerun: yes">   +-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
It would be great if you could confirm if = length can be greater than 8 for ASPAC messages or it has to be always set to 8 for ASPAC as well.
 
Thank you in = advance for your views on this matter.
 =
Thanks and Regards
Supreet Jain
 
<= /div>

From: Brian F. G. Bidulock <bidulock@openss7.org>
To: R= ajesh Makhija <rajesh.ma= khija@aricent.com>
Cc: "sigtran@ietf.org" <sigtran@ietf.org>; "sigtran@ietfa.amsl.com" <= ;sigtran@ietfa.amsl.com>; "supreet_jain@yahoo.com" <supreet_jain@yaho= o.com>
Sent: Tuesday,= August 30, 2011 8:47 AM
Subject: Re: [Sigtran] Interface Identifier in= ASPTM message in M2UA

Rajesh,

Read RFC 3331/Page 22:

  The Tag value= for the Integer-based Interface Identifier is 0x1.  The
  len= gth is always set to a value of 8.

--brian

--
Brian F. G. Bidulock
bidulock@openss7= .org
http://www.= openss7.org/


--0-1205768417-1314699855=:37564--