From rajesh.makhija@aricent.com Thu Sep 1 01:49: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 30B4021F8563 for ; Thu, 1 Sep 2011 01:49:23 -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 SGi7+SDFdl6y for ; Thu, 1 Sep 2011 01:49:20 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4F121F84E1 for ; Thu, 1 Sep 2011 01:49:19 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 4136B36BC8; Thu, 1 Sep 2011 14:15:25 +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 29DB836BC7; Thu, 1 Sep 2011 14:15:25 +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; Thu, 1 Sep 2011 14:20:49 +0530 From: Rajesh Makhija To: "sigtran@ietf.org" , "sigtran@ietfa.amsl.com" Date: Thu, 1 Sep 2011 14:20:47 +0530 Thread-Topic: [Sigtran] Interface Identifier in ASPTM message in M2UA Thread-Index: AcxmPfHGC6L7SqdQRfCxEYSuPFTqFwAAM+EwAJFL/BA= 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_ED87E3B738CE6240A27EC10A62BE60AE28C7598385GUREXMB01ASIA_" MIME-Version: 1.0 Cc: "supreet_jain@yahoo.com" , Rajesh Makhija 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, 01 Sep 2011 08:49:23 -0000 --_000_ED87E3B738CE6240A27EC10A62BE60AE28C7598385GUREXMB01ASIA_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello It would be nice to reach a consensus on this matter. Requesting Brian and = other forum member to share their valuable insights.....on last input from = Supreet ------------ Hi Brain, Thank you for giving insights on this matter. It is now very clear that th= e length field should be equal to 8 for MAUP messages. I would request you to throw some light for messages other than MAUP (such = as ASPAC). RFC 3331, section 3.2 states that: ----- =E2The Tag value for the Integer-based Interface Identifier is 0x1. The l= ength is always set to a value of 8.=E2 =E2The M2UA specific message header will immediately follow the common m= essage header, but will =E2only=E2 be used with =E2MAUP=E2 messages.=E2 ---- As per RFC 3331, "The M2UA specific message header will immediately follow = 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 t= he value of length field. As per RFC section 3.3.2.7, from the ASPAC message format it appears that m= ultiple interface identifiers values can be used along with a single tag (0= x1)=E2. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xb) | Length =3D 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Mode Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1=3Dinteger) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Interface Identifiers* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 ---------- ________________________________ From: Rajesh Makhija Sent: Monday, August 29, 2011 4:59 PM To: 'sigtran@ietf.org'; 'sigtran@ietfa.amsl.com' Cc: 'supreet_jain@yahoo.com'; 'aditi.someshwar@gmail.com' Subject: Re: [Sigtran] Interface Identifier in ASPTM message in M2UA 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_ED87E3B738CE6240A27EC10A62BE60AE28C7598385GUREXMB01ASIA_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello

 

It would be nice to reach a consensus = on this matter. Requesting Brian and other forum member to share their valu= able insights…..on last input from Supreet

 

------------<= /p>

Hi Brai= n,

 <= o:p>

= 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.

&= nbsp;

I would request you to throw some light for messages ot= her than MAUP (such as ASPAC).

=  

RFC 3331, section 3.2 states that:

= -----

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

&= nbsp;

 = =E2The M2UA specific message header will   immediately follow the common message header, but will =E2only=E2 be used   with =E2MAUP=E2 messages.=E2

----

&= nbsp;

As per RFC 3331, "The M2UA=  specific message header will immediately follow the common message header, but= will only be used with MAUP messages".

&= nbsp;

For ASPTM&n= bsp;(such as ASPAC) messages it is not very clear on what should be the value = of length field.

&= nbsp;

As per = RFC section 3.3.2.7, from the ASPAC message format it appears that multiple interface identifiers values can be used a= long with a single tag (0x1)=E2.

&= nbsp;

&= nbsp;

&= nbsp;

  =  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

  =  +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+<= font color=3D"black">

  =  |          <= span class=3D"apple-converted-space"> Tag (0xb)      &= nbsp;    |=             Length =3D 8   &nb= sp;     |

  =  +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+<= font color=3D"black">

  =  |          &= nbsp;    &= nbsp;     Traffic Mode Type           = ;            &n= bsp; |

  =  +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+<= font color=3D"black">

  =  |     Tag (0x1=3Dinteger)       =   |   = ;         Length       &n= bsp;     |

  =  +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+<= font color=3D"black">

  =  /          &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  \<= /o:p>

  =  \          &= nbsp;          Interface Identifiers*          &n= bsp;         /

  =  /          &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  \<= /o:p>

  =  +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+<= font color=3D"black">

 

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&= nbsp;ASPAC as well.

&= nbsp;

Thank y= ou in advance for your views on this matter.

 <= o:p>

Thanks = and Regards

Supreet= Jain

----------


From: Raje= sh Makhija
Sent: Monday, August 29, 201= 1 4:59 PM
To: 'sigtran@ietf.org'; 'sigtr= an@ietfa.amsl.com'
Cc: 'supreet_jain@yahoo.com'; 'aditi.someshwar@gmail.com' Subject: Re: [Sigtran] Inter= face Identifier in ASPTM message in M2UA

 

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_ED87E3B738CE6240A27EC10A62BE60AE28C7598385GUREXMB01ASIA_-- From rajesh.makhija@aricent.com Thu Sep 1 01:49:31 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 0E74921F8B63 for ; Thu, 1 Sep 2011 01:49:31 -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 PoO3eeqtF9Il for ; Thu, 1 Sep 2011 01:49:30 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3C56A21F8AAC for ; Thu, 1 Sep 2011 01:49:29 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 4136B36BC8; Thu, 1 Sep 2011 14:15:25 +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 29DB836BC7; Thu, 1 Sep 2011 14:15:25 +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; Thu, 1 Sep 2011 14:20:49 +0530 From: Rajesh Makhija To: "sigtran@ietf.org" , "sigtran@ietfa.amsl.com" Date: Thu, 1 Sep 2011 14:20:47 +0530 Thread-Topic: [Sigtran] Interface Identifier in ASPTM message in M2UA Thread-Index: AcxmPfHGC6L7SqdQRfCxEYSuPFTqFwAAM+EwAJFL/BA= 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_ED87E3B738CE6240A27EC10A62BE60AE28C7598385GUREXMB01ASIA_" MIME-Version: 1.0 Cc: "supreet_jain@yahoo.com" , Rajesh Makhija 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, 01 Sep 2011 08:49:31 -0000 --_000_ED87E3B738CE6240A27EC10A62BE60AE28C7598385GUREXMB01ASIA_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello It would be nice to reach a consensus on this matter. Requesting Brian and = other forum member to share their valuable insights.....on last input from = Supreet ------------ Hi Brain, Thank you for giving insights on this matter. It is now very clear that th= e length field should be equal to 8 for MAUP messages. I would request you to throw some light for messages other than MAUP (such = as ASPAC). RFC 3331, section 3.2 states that: ----- =E2The Tag value for the Integer-based Interface Identifier is 0x1. The l= ength is always set to a value of 8.=E2 =E2The M2UA specific message header will immediately follow the common m= essage header, but will =E2only=E2 be used with =E2MAUP=E2 messages.=E2 ---- As per RFC 3331, "The M2UA specific message header will immediately follow = 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 t= he value of length field. As per RFC section 3.3.2.7, from the ASPAC message format it appears that m= ultiple interface identifiers values can be used along with a single tag (0= x1)=E2. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xb) | Length =3D 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Mode Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1=3Dinteger) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Interface Identifiers* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 ---------- ________________________________ From: Rajesh Makhija Sent: Monday, August 29, 2011 4:59 PM To: 'sigtran@ietf.org'; 'sigtran@ietfa.amsl.com' Cc: 'supreet_jain@yahoo.com'; 'aditi.someshwar@gmail.com' Subject: Re: [Sigtran] Interface Identifier in ASPTM message in M2UA 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_ED87E3B738CE6240A27EC10A62BE60AE28C7598385GUREXMB01ASIA_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello

 

It would be nice to reach a consensus = on this matter. Requesting Brian and other forum member to share their valu= able insights…..on last input from Supreet

 

------------<= /p>

Hi Brai= n,

 <= o:p>

= 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.

&= nbsp;

I would request you to throw some light for messages ot= her than MAUP (such as ASPAC).

=  

RFC 3331, section 3.2 states that:

= -----

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

&= nbsp;

 = =E2The M2UA specific message header will   immediately follow the common message header, but will =E2only=E2 be used   with =E2MAUP=E2 messages.=E2

----

&= nbsp;

As per RFC 3331, "The M2UA=  specific message header will immediately follow the common message header, but= will only be used with MAUP messages".

&= nbsp;

For ASPTM&n= bsp;(such as ASPAC) messages it is not very clear on what should be the value = of length field.

&= nbsp;

As per = RFC section 3.3.2.7, from the ASPAC message format it appears that multiple interface identifiers values can be used a= long with a single tag (0x1)=E2.

&= nbsp;

&= nbsp;

&= nbsp;

  =  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

  =  +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+<= font color=3D"black">

  =  |          <= span class=3D"apple-converted-space"> Tag (0xb)      &= nbsp;    |=             Length =3D 8   &nb= sp;     |

  =  +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+<= font color=3D"black">

  =  |          &= nbsp;    &= nbsp;     Traffic Mode Type           = ;            &n= bsp; |

  =  +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+<= font color=3D"black">

  =  |     Tag (0x1=3Dinteger)       =   |   = ;         Length       &n= bsp;     |

  =  +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+<= font color=3D"black">

  =  /          &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  \<= /o:p>

  =  \          &= nbsp;          Interface Identifiers*          &n= bsp;         /

  =  /          &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  \<= /o:p>

  =  +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+<= font color=3D"black">

 

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&= nbsp;ASPAC as well.

&= nbsp;

Thank y= ou in advance for your views on this matter.

 <= o:p>

Thanks = and Regards

Supreet= Jain

----------


From: Raje= sh Makhija
Sent: Monday, August 29, 201= 1 4:59 PM
To: 'sigtran@ietf.org'; 'sigtr= an@ietfa.amsl.com'
Cc: 'supreet_jain@yahoo.com'; 'aditi.someshwar@gmail.com' Subject: Re: [Sigtran] Inter= face Identifier in ASPTM message in M2UA

 

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_ED87E3B738CE6240A27EC10A62BE60AE28C7598385GUREXMB01ASIA_-- From bidulock@openss7.org Thu Sep 1 02:29:59 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 1134121F8B36 for ; Thu, 1 Sep 2011 02:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 qy1Hyui-ZXVW for ; Thu, 1 Sep 2011 02:29:58 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.117.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1292321F8B0F for ; Thu, 1 Sep 2011 02:29:57 -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 p819VLss006479; Thu, 1 Sep 2011 03:31:21 -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 p819VKw1016837; Thu, 1 Sep 2011 03:31:20 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p819VIsr016831; Thu, 1 Sep 2011 03:31:18 -0600 Date: Thu, 1 Sep 2011 03:31:17 -0600 From: "Brian F. G. Bidulock" To: Rajesh Makhija Message-ID: <20110901093117.GA15295@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: Thu, 01 Sep 2011 09:29:59 -0000 Rajesh, I think the diagram on Page 36/RFC 3331 is quite self-explanatory. There is really only one way to interpret it. --brian Rajesh Makhija wrote: (Thu, 01 Sep 2011 14:20:47) > Hello > > > It would be nice to reach a consensus on this matter. Requesting Brian > and other forum member to share their valuable insights.....on last > input from Supreet > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From bidulock@openss7.org Thu Sep 1 02:29:59 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 C74E921F8B36 for ; Thu, 1 Sep 2011 02:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 Y-Wxzpgx4WgI for ; Thu, 1 Sep 2011 02:29:59 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.117.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD9521F8B0F for ; Thu, 1 Sep 2011 02:29:59 -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 p819VLss006479; Thu, 1 Sep 2011 03:31:21 -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 p819VKw1016837; Thu, 1 Sep 2011 03:31:20 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p819VIsr016831; Thu, 1 Sep 2011 03:31:18 -0600 Date: Thu, 1 Sep 2011 03:31:17 -0600 From: "Brian F. G. Bidulock" To: Rajesh Makhija Message-ID: <20110901093117.GA15295@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: Thu, 01 Sep 2011 09:29:59 -0000 Rajesh, I think the diagram on Page 36/RFC 3331 is quite self-explanatory. There is really only one way to interpret it. --brian Rajesh Makhija wrote: (Thu, 01 Sep 2011 14:20:47) > Hello > > > It would be nice to reach a consensus on this matter. Requesting Brian > and other forum member to share their valuable insights.....on last > input from Supreet > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From santhana@huawei.com Thu Sep 1 20:00:57 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 97A9221F9386 for ; Thu, 1 Sep 2011 20:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.768 X-Spam-Level: X-Spam-Status: No, score=-4.768 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] 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 moXW8XrklzNE for ; Thu, 1 Sep 2011 20:00:57 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id E828F21F937D for ; Thu, 1 Sep 2011 20:00:56 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQV00A9DKFQJ1@szxga05-in.huawei.com> for sigtran@ietf.org; Fri, 02 Sep 2011 11:02:14 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQV0073JKFPT5@szxga05-in.huawei.com> for sigtran@ietf.org; Fri, 02 Sep 2011 11:02:14 +0800 (CST) Received: from BLRNSHTIPL2NC ([10.18.1.32]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LQV005VQKFOUB@szxml04-in.huawei.com> for sigtran@ietf.org; Fri, 02 Sep 2011 11:02:13 +0800 (CST) Date: Fri, 02 Sep 2011 08:14:14 +0530 From: Santhana To: sigtran@ietf.org Message-id: <6C12A37EC14548A2BA8646F2B772716E@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_xB59aip2CDMRmIvwEi9JBw)" Thread-index: AcxpGjOgjG0Q4xCTRz+Rs4CEeLA/yA== Subject: [Sigtran] [M3UA] Handling DUNA about Self Point Code 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: Fri, 02 Sep 2011 03:00:57 -0000 This is a multi-part message in MIME format. --Boundary_(ID_xB59aip2CDMRmIvwEi9JBw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Brian In M3UA can an entity send DUNA(about itself), to convey its unavailability, for some other Management reasons. If such DUNA(about self Point Code) is received from adjacent Point Code, then how to process it ? Can it be processed like normal DUNA, and a DAUD procedure be started? Or for management reasons the control should be only at the level of Blocking the ASP? Pls share your opinion. Regards Santhana --Boundary_(ID_xB59aip2CDMRmIvwEi9JBw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Brian

          In M3UA can an entity send DUNA(about itself), to convey its unavailability, for some other Management reasons. 

 

          If such DUNA(about self Point Code) is received from adjacent Point Code, then how to process it ? Can it be processed like normal DUNA, and a DAUD procedure be started?

 

          Or for management reasons the control should be only at the level of Blocking the ASP?

 

          Pls share your opinion.

 

Regards

Santhana

--Boundary_(ID_xB59aip2CDMRmIvwEi9JBw)-- From bidulock@openss7.org Fri Sep 2 00:53:13 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 AAC4221F91B5 for ; Fri, 2 Sep 2011 00:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_45=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 q7zQvSZa4ynt for ; Fri, 2 Sep 2011 00:53:13 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.117.178]) by ietfa.amsl.com (Postfix) with ESMTP id A86AF21F91B1 for ; Fri, 2 Sep 2011 00:53:08 -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 p827sUmf012681; Fri, 2 Sep 2011 01:54:30 -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 p827sUO0016876; Fri, 2 Sep 2011 01:54:30 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p827sSSl016874; Fri, 2 Sep 2011 01:54:28 -0600 Date: Fri, 2 Sep 2011 01:54:28 -0600 From: "Brian F. G. Bidulock" To: Santhana Message-ID: <20110902075428.GA14460@openss7.org> Mail-Followup-To: Santhana , sigtran@ietf.org References: <6C12A37EC14548A2BA8646F2B772716E@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6C12A37EC14548A2BA8646F2B772716E@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] Handling DUNA about Self Point Code 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: Fri, 02 Sep 2011 07:53:13 -0000 Santhana, Why would one ever do something like that? In IPSP configuration, SNMM are not used (M3UA is point-to-point in IPSP mode). So, I can only conceive that you mean SG-ASP mode. In SG-ASP mode, an ASP signals its unavailability to service an AS using ASPIA. An ASP sending DUNA for the point code associated with an AS is not only wrong (other ASPs can still serve the AS), it is not specified (DUNA is only sent from SG to ASP). So, I don't suppose that you mean an ASP sending DUNA, but an SG. An SG sends DUNA for a specific point code when that point code is unavailable to the SG. That is, when the routeset from the SG to the remote point code is transfer-prohibited. Transfer of MTP messages to a local point code is always available unless the MTP layer at the SG is unavailable. There are two proscribed procedures at the SG for handling partitioning: when the SG is separated from the SS7 network and unable to transfer any MTP messages to remote point codes (e.g. isolation at the NIF) it can send DUNA(*) to indicate the isolation. This means that the SG cannot send MTP messages to *any* *remote* point code. You see that DUNA means that MTP messages cannot be transferred *to* the destination point code. The second procedure is when the SG is unable to support an AS (local point code). In this case the SG can send unsolicited ASPIA Ack for the affected AS to the affected ASPs. When the ASP attempts to reactivate the AS using ASPAC, it returns ERROR(management blocking) until the fault clears. When the SG is unable to serve *any* AS, it an send unsolicited ASPDN Ack, and return ERROR(management blocking) when the ASP attempts ASPUP until the fault clears. The only case where I can see that an SG would send DUNA for a point code belonging to an AS to an ASP serving that AS would be where it is prohibited for an ASP to send a message from a point code belonging to the AS to another (or the same) point code belonging to the AS. So, for example, if the AS attempted to send data from point code 1-1-1 to point code 1-1-1, the SG could reply with DUNA(1-1-1). Is that what you were meaning? --brian Santhana wrote: (Fri, 02 Sep 2011 08:14:14) > Hi Brian > > In M3UA can an entity send DUNA(about itself), to convey its > unavailability, for some other Management reasons. > > > If such DUNA(about self Point Code) is received from adjacent > Point Code, then how to process it ? Can it be processed like normal > DUNA, and a DAUD procedure be started? > > > Or for management reasons the control should be only at the > level of Blocking the ASP? > > > Pls share your opinion. > > > Regards > > Santhana -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From santhana@huawei.com Fri Sep 2 01:41:17 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 6CDF321F8B5D for ; Fri, 2 Sep 2011 01:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.084 X-Spam-Level: X-Spam-Status: No, score=-5.084 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] 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 DHI4l0FaIWTk for ; Fri, 2 Sep 2011 01:41:16 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5BA21F8B56 for ; Fri, 2 Sep 2011 01:41:16 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQW00K2K05J8Q@szxga05-in.huawei.com> for sigtran@ietf.org; Fri, 02 Sep 2011 16:41:44 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQW00EA705J13@szxga05-in.huawei.com> for sigtran@ietf.org; Fri, 02 Sep 2011 16:41:43 +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 <0LQW007PA05IWK@szxml06-in.huawei.com> for sigtran@ietf.org; Fri, 02 Sep 2011 16:41:43 +0800 (CST) Date: Fri, 02 Sep 2011 13:53:43 +0530 From: Santhana In-reply-to: <20110902075428.GA14460@openss7.org> To: bidulock@openss7.org Message-id: <020D83DA676E4E959A65DC172D86EDA5@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: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcxpRZT6FmxO9GFyR+SqI6XUnLe7mAAAot8g References: <6C12A37EC14548A2BA8646F2B772716E@china.huawei.com> <20110902075428.GA14460@openss7.org> Cc: sigtran@ietf.org Subject: Re: [Sigtran] [M3UA] Handling DUNA about Self Point Code 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: Fri, 02 Sep 2011 08:41:17 -0000 Hi Brian I meant SG-ASP mode only and also SG sending DUNA about itself to an AS. Now it is clear from your reply that we must do this with unsolicited INACTIVE-ACK or DOWN-ACK from SG to ASP. So if such DUNA(about self PC) comes from SG, then the handling behavior in ASP could be just discarding it right ? I could not understand the below scenario described by you. Can u explain ? " The only case where I can see that an SG would send DUNA for a point code belonging to an AS to an ASP serving that AS would be where it is prohibited for an ASP to send a message from a point code belonging to the AS to another (or the same) point code belonging to the AS. So, for example, if the AS attempted to send data from point code 1-1-1 to point code 1-1-1, the SG could reply with DUNA(1-1-1). Is that what you were meaning?" Thanks & regards Santhana -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] Sent: Friday, September 02, 2011 1:24 PM To: Santhana Cc: sigtran@ietf.org Subject: Re: [Sigtran] [M3UA] Handling DUNA about Self Point Code Santhana, Why would one ever do something like that? In IPSP configuration, SNMM are not used (M3UA is point-to-point in IPSP mode). So, I can only conceive that you mean SG-ASP mode. In SG-ASP mode, an ASP signals its unavailability to service an AS using ASPIA. An ASP sending DUNA for the point code associated with an AS is not only wrong (other ASPs can still serve the AS), it is not specified (DUNA is only sent from SG to ASP). So, I don't suppose that you mean an ASP sending DUNA, but an SG. An SG sends DUNA for a specific point code when that point code is unavailable to the SG. That is, when the routeset from the SG to the remote point code is transfer-prohibited. Transfer of MTP messages to a local point code is always available unless the MTP layer at the SG is unavailable. There are two proscribed procedures at the SG for handling partitioning: when the SG is separated from the SS7 network and unable to transfer any MTP messages to remote point codes (e.g. isolation at the NIF) it can send DUNA(*) to indicate the isolation. This means that the SG cannot send MTP messages to *any* *remote* point code. You see that DUNA means that MTP messages cannot be transferred *to* the destination point code. The second procedure is when the SG is unable to support an AS (local point code). In this case the SG can send unsolicited ASPIA Ack for the affected AS to the affected ASPs. When the ASP attempts to reactivate the AS using ASPAC, it returns ERROR(management blocking) until the fault clears. When the SG is unable to serve *any* AS, it an send unsolicited ASPDN Ack, and return ERROR(management blocking) when the ASP attempts ASPUP until the fault clears. The only case where I can see that an SG would send DUNA for a point code belonging to an AS to an ASP serving that AS would be where it is prohibited for an ASP to send a message from a point code belonging to the AS to another (or the same) point code belonging to the AS. So, for example, if the AS attempted to send data from point code 1-1-1 to point code 1-1-1, the SG could reply with DUNA(1-1-1). Is that what you were meaning? --brian Santhana wrote: (Fri, 02 Sep 2011 08:14:14) > Hi Brian > > In M3UA can an entity send DUNA(about itself), to convey its > unavailability, for some other Management reasons. > > > If such DUNA(about self Point Code) is received from adjacent > Point Code, then how to process it ? Can it be processed like normal > DUNA, and a DAUD procedure be started? > > > Or for management reasons the control should be only at the > level of Blocking the ASP? > > > Pls share your opinion. > > > Regards > > Santhana -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From plotkin@pisem.net Fri Sep 2 03:04:28 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 0AA8621F8D22 for ; Fri, 2 Sep 2011 03:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875] 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 Q9Xs+4H2Onkm for ; Fri, 2 Sep 2011 03:04:26 -0700 (PDT) Received: from web25.pochta.ru (web25.pochta.ru [62.141.94.205]) by ietfa.amsl.com (Postfix) with ESMTP id 8D16821F8D35 for ; Fri, 2 Sep 2011 03:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qip.ru; s=dkim; h=Content-Transfer-Encoding:Content-Type:Message-Id:Date:Subject:To:Sender:From; bh=5ToV0UNJ80094Ef/J532IKiKHw6TgbWayq7X6OQSN4A=; b=Lv/Blp5xRk6fD3LNykstSySFWeKGZqT93vBEZnw9WloWmCHill3eIIoySgMwmVIx79Vdcg9cysLE/biAfyUmWt+JAoJKW7lpiAEWxdMuUPrBwAXoeR+Et5+wy10824VU; Received: from [127.0.0.1] (port=40544 helo=localhost) by web25.pochta.ru with esmtp id 1QzQdH-00060z-Az for sigtran@ietf.org; Fri, 02 Sep 2011 14:05:55 +0400 From: Mikhail Plotkin Sender: plotkin@pisem.net To: sigtran@ietf.org Date: Fri, 02 Sep 2011 14:05:55 +0400 Message-Id: <81059a00bf504529899e311fa7954479bcbc25b1@mail.qip.ru> X-Priority: 3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-NoSpam-Exim-Host: 62.141.94.133 X-NoSpam-Exim-Port: 8092 X-NoSpam-Exim-Scanned: Yes X-NoSpam-Exim-Result: OK Subject: [Sigtran] SCON received at ASP from one of SGs 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: Fri, 02 Sep 2011 10:04:28 -0000 =0D=0A =0D=0A Normal=0D=0A 0=0D=0A =0D=0A =0D=0A =0D=0A =0D=0A fa= lse=0D=0A false=0D=0A false=0D=0A =0D=0A RU=0D=0A X-NONE=0D=0A X-N= ONE=0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A= =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A MicrosoftInternet= Explorer4=0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A = =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A=0D=0A =0D=0A = =0D=0A =0D=0A= =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A= =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A= =0D=0A =0D=0A= =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A <= w:lsdexception locked=3D"false" priority=3D"62" semihidden=3D"false" unh= idewhenused=3D"false" name=3D"Light Grid">=0D=0A =0D=0A =0D=0A =0D=0A= =0D=0A =0D=0A =0D=0A =0D= =0A =0D=0A =0D=0A =0D=0A =0D= =0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A = =0D=0A =0D=0A <= w:lsdexception locked=3D"false" priority=3D"69" semihidden=3D"false" unh= idewhenused=3D"false" name=3D"Medium Grid 3 Accent 1">=0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A = =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A= =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A = =0D=0A =0D=0A <= w:lsdexception locked=3D"false" priority=3D"66" semihidden=3D"false" unh= idewhenused=3D"false" name=3D"Medium List 2 Accent 3">=0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A= =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D= =0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D= =0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A = =0D=0A =0D=0A= =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D= =0A =0D=0A =0D=0A =0D=0A <= w:lsdexception locked=3D"false" priority=3D"31" semihidden=3D"false" unh= idewhenused=3D"false" qformat=3D"true" name=3D"Subtle Reference">=0D=0A= = =0D=0A =0D= =0A =0D=0A =0D=0A =0D=0A=0D=0A=0D=0A /* Style Definitions */=0D=0A tab= le.MsoNormalTable=0D=0A=09{mso-style-name:"Table Normal";=0D=0A=09mso-ts= tyle-rowband-size:0;=0D=0A=09mso-tstyle-colband-size:0;=0D=0A=09mso-styl= e-noshow:yes;=0D=0A=09mso-style-priority:99;=0D=0A=09mso-style-qformat:y= es;=0D=0A=09mso-style-parent:"";=0D=0A=09mso-padding-alt:0cm 5.4pt 0cm 5= .4pt;=0D=0A=09mso-para-margin:0cm;=0D=0A=09mso-para-margin-bottom:.0001p= t;=0D=0A=09mso-pagination:widow-orphan;=0D=0A=09font-size:11.0pt;=0D=0A= =09font-family:"Calibri","sans-serif";=0D=0A=09mso-ascii-font-family:Cal= ibri;=0D=0A=09mso-ascii-theme-font:minor-latin;=0D=0A=09mso-fareast-font= -family:"Times New Roman";=0D=0A=09mso-fareast-theme-font:minor-fareast;= =0D=0A=09mso-hansi-font-family:Calibri;=0D=0A=09mso-hansi-theme-font:min= or-latin;=0D=0A=09mso-bidi-font-family:"Times New Roman";=0D=0A=09mso-bi= di-theme-font:minor-bidi;}=0D=0A=0D=0A=0D=0A=0D=0AHi All,=0D=0AHope to g= et a piece of advise regarding interpretation of sections 1.3.2 and 4.5.= 2.2 of RFC4666.=0D=0A=0D=0A=0D=0A=0D=0AASP has=0D=0Aroutes to SS7 destin= ation point through several SGs.=0D=0A=0D=0A1 . If ASP gets SCON from on= e of SGs should it immediately send congestion indication=0D=0Ato the us= er or should we send report to the user if and only if SCON received fro= m both SGs? RFC says that ASP "determines whether or=0D=0A not the ove= rall availability or congestion status of the affected=0D=0A destinati= on(s) has changed". Does it mean ASP should set for the destination the= minimum congestion status among all SGs or the maximum congestion statu= s among all SGs ?=0D=0A=0D=0A=0D=0A 2. In the=0D=0Asame configurati= on. If we get SCON from one SG should we try to redistribute=0D=0Athe pa= rt of traffic from the congested route, that leads to congestion, to the= other routes  through which this destination is accessible?=0D=0A= =0D=0AIf yes,=0D=0Awhat measures can be taken to diminish possible negat= ive side effects of such=0D=0Aredistribution? By the way, RFC recommends= to handle it "much like an MTP3 layer=0D=0A maintains route-set statu= s", but ITU-T Q.704 does not say anything about rerouting caused by cong= estion in one of the routes.=0D=0A=0D=0A=0D=0A=0D=0A(Similar questions h= ave been discussed here before, but those were for several ASPs and a si= ngle SG)=0D=0A=0D=0A=0D=0A<= /w:lsdexception>= From plotkin@pisem.net Fri Sep 2 03:09:11 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 A912F21F8FB5 for ; Fri, 2 Sep 2011 03:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.304 X-Spam-Level: X-Spam-Status: No, score=0.304 tagged_above=-999 required=5 tests=[AWL=-1.433, BAYES_40=-0.185, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 YLBKtPcsdAne for ; Fri, 2 Sep 2011 03:09:11 -0700 (PDT) Received: from web22.pochta.ru (web22.pochta.ru [62.141.94.202]) by ietfa.amsl.com (Postfix) with ESMTP id B77A121F9001 for ; Fri, 2 Sep 2011 03:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qip.ru; s=dkim; h=MIME-Version:Content-Type:Message-Id:Date:References:In-Reply-To:Subject:To:Sender:From; bh=7qV8tgZmTICN6fzG2UC8hF4Z8iD3qiFSN27YHUmR0dk=; b=rHAN3CaGZSDaSEmkAE3OzXxOTWGBgqHAHPz6M1NFkI6PsAYkvqbRggug2LrgeettnQS5Lu4k+F18M/555oy6BFqJ2fooPwJii0tHjCbhuUSX1XciJ5DNTgW+lefJSggQ; Received: from [127.0.0.1] (port=52610 helo=localhost) by web22.pochta.ru with esmtp id 1QzQht-0008Al-Bx for sigtran@ietf.org; Fri, 02 Sep 2011 14:10:41 +0400 From: Mikhail Plotkin Sender: plotkin@pisem.net To: sigtran@ietf.org In-Reply-To: <81059a00bf504529899e311fa7954479bcbc25b1@mail.qip.ru> References: <81059a00bf504529899e311fa7954479bcbc25b1@mail.qip.ru> Date: Fri, 02 Sep 2011 14:10:41 +0400 Message-Id: X-Priority: 3 Content-Type: multipart/alternative; charset="utf-8"; boundary="=_10cfae2003d08c372524a97d204c20e7" MIME-Version: 1.0 X-NoSpam-Exim-Host: 62.141.94.133 X-NoSpam-Exim-Port: 8092 X-NoSpam-Exim-Scanned: Yes X-NoSpam-Exim-Result: OK Subject: Re: [Sigtran] =?utf-8?q?SCON_received_a=C2=ADt_ASP_from_one_of_SGs?= 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: Fri, 02 Sep 2011 10:09:11 -0000 --=_10cfae2003d08c372524a97d204c20e7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sorry for the previous mail, there was something with the format.=0A=0A>= Hi All,=0A> Hope to get a piece of advise regarding interpretation of s= ections 1.3.2 and 4.5.2.2 of RFC4666.=0A> =0A> ASP has=0A> routes to SS7= destination point through several SGs.=0A> =0A> 1 . If ASP gets SCON fr= om one of SGs should it immediately send congestion indication=0A> to th= e user or should we send report to the user if and only if SCON received= from both SGs? RFC says that ASP "determines whether or=0A> not the= overall availability or congestion status of the affected=0A> destin= ation(s) has changed". Does it mean ASP should set for the destination t= he minimum congestion status among all SGs or the maximum congestion sta= tus among all SGs ?=0A> =0A> 2. In the=0A> same configuration. If we get= SCON from one SG should we try to redistribute=0A> the part of traffic= from the congested route, that leads to congestion, to the other routes= through which this destination is accessible?=0A> =0A> If yes,=0A> wha= t measures can be taken to diminish possible negative side effects of su= ch=0A> redistribution? By the way, RFC recommends to handle it "much lik= e an MTP3 layer=0A> maintains route-set status", but ITU-T Q.704 does= not say anything about rerouting caused by congestion in one of the rou= tes.=0A> =0A> (Similar questions have been discussed here before, but th= ose were for several ASPs and a single SG)=0A=0ARegards, Mikhail. --=_10cfae2003d08c372524a97d204c20e7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sorry for the previous mail, there was something with the format.
> Hi All,
> Hope to get a piece of advise regarding interpreta= tion of sections 1.3.2 and 4.5.2.2 of RFC4666.
>
> ASP has<= br>> routes to SS7 destination point through several SGs.
> > 1 . If ASP gets SCON from one of SGs should it immediately send co= ngestion indication
> to the user or should we send report to the= user if and only if SCON received from both SGs? RFC says that ASP "det= ermines whether or
> not the overall availability or congestion= status of the affected
> destination(s) has changed". Does it= mean ASP should set for the destination the minimum congestion status a= mong all SGs or the maximum congestion status among all SGs ?
> > 2. In the
> same configuration. If we get SCON from one SG= should we try to redistribute
> the part of traffic from the cong= ested route, that leads to congestion, to the other routes  through= which this destination is accessible?
>
> If yes,
>= what measures can be taken to diminish possible negative side effects o= f such
> redistribution? By the way, RFC recommends to handle it "= much like an MTP3 layer
> maintains route-set status", but ITU-= T Q.704 does not say anything about rerouting caused by congestion in on= e of the routes.
>
> (Similar questions have been discussed= here before, but those were for several ASPs and a single SG)

Re= gards, Mikhail.
--=_10cfae2003d08c372524a97d204c20e7-- From sandeepsinghmails@gmail.com Fri Sep 2 05:17: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 777AC21F8B3B for ; Fri, 2 Sep 2011 05:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 93sqoxpebQsc for ; Fri, 2 Sep 2011 05:17:26 -0700 (PDT) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD5B21F8C8F for ; Fri, 2 Sep 2011 05:17:07 -0700 (PDT) Received: by wwi36 with SMTP id 36so2241559wwi.7 for ; Fri, 02 Sep 2011 05:18:42 -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 :content-type; bh=4lrrHXK8hRMjYi/J7gtoervFMYCBb/HE+n9ap1qZWSg=; b=DOGMb8rKlM5phS07pK/p5DZoDoApCj/ttRJJifGmwzfXs81Py/Jeir9a+II3GA3ybc gH/uc7ffAfNRHCQa+OB31B4B7To9RAkB58MAP1K46ADqH/H/Xc9vp1GDJShK2yiYrDKt WEF7CoiFSmlUR6SYyzQSZDoUkx11Ve25G84GE= MIME-Version: 1.0 Received: by 10.216.229.200 with SMTP id h50mr1326781weq.32.1314965921857; Fri, 02 Sep 2011 05:18:41 -0700 (PDT) Received: by 10.216.30.135 with HTTP; Fri, 2 Sep 2011 05:18:41 -0700 (PDT) In-Reply-To: <20110901093117.GA15295@openss7.org> References: <20110901093117.GA15295@openss7.org> Date: Fri, 2 Sep 2011 17:48:41 +0530 Message-ID: From: Sandeep Singh To: bidulock@openss7.org, Rajesh Makhija , "sigtran@ietf.org" , "sigtran@ietfa.amsl.com" , "supreet_jain@yahoo.com" Content-Type: multipart/alternative; boundary=0016e6567f98aa00e704abf45cd5 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: Fri, 02 Sep 2011 12:17:27 -0000 --0016e6567f98aa00e704abf45cd5 Content-Type: text/plain; charset=ISO-8859-1 Hi everybody, Thanks for your valuable inputs. It is very clear from *Page 36 of RFC 3331* that the length of Interface Identifier Set having Tag (0x1) can have Length more than 8. According to the following figure, the length should be *(n*4 + 4)* if there are n Interface Identifiers: Please let me know if there is anything wrong in my understanding. Best Regards, Sandeep Singh On Thu, Sep 1, 2011 at 3:01 PM, Brian F. G. Bidulock wrote: > Rajesh, > > I think the diagram on Page 36/RFC 3331 is quite self-explanatory. There > is really only one way to interpret it. > > --brian > > Rajesh Makhija wrote: (Thu, 01 Sep 2011 14:20:47) > > Hello > > > > > > It would be nice to reach a consensus on this matter. Requesting Brian > > and other forum member to share their valuable insights.....on last > > input from Supreet > > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > --0016e6567f98aa00e704abf45cd5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi everybody,=A0=A0

Thanks for your valuable inputs.

It is very clear from Page 36 of RFC 3331 that the length of Interfa= ce=20 Identifier Set having Tag (0x1) can have Length more than 8.

According to the following figure, the length should be (n*4 + 4) if= there are n Interface Identifiers:

3D""
Please let me know if there is anything wrong in my understanding.


Best Regards,

Sandeep Singh


On Thu, Sep 1, 2011 at 3:01 PM, Brian F.= G. Bidulock <= bidulock@openss7.org> wrote:
Rajesh,

I think the diagram on Page 36/RFC 3331 is quite self-explanatory. =A0There=
is really only one way to interpret it.

--brian

Rajesh Makhija wrote: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (Thu, 01 = Sep 2011 14:20:47)
> =A0 =A0Hello
>
>
> =A0 =A0It would be nice to reach a consensus on this matter. Requestin= g Brian
> =A0 =A0and other forum member to share their valuable insights.....on = last
> =A0 =A0input from Supreet
>

--
___________________________________= ____________
Sigtran mailing list
Sigtran@ietf.org
https://www.ietf.org/mailman/listinfo/sigtran

--0016e6567f98aa00e704abf45cd5-- From sandeepsinghmails@gmail.com Fri Sep 2 05:17: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 7D5A721F8B51 for ; Fri, 2 Sep 2011 05:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 YVzVh878ug2P for ; Fri, 2 Sep 2011 05:17:26 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D0A3B21F8C89 for ; Fri, 2 Sep 2011 05:17:06 -0700 (PDT) Received: by wyg8 with SMTP id 8so2549382wyg.31 for ; Fri, 02 Sep 2011 05:18:42 -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 :content-type; bh=4lrrHXK8hRMjYi/J7gtoervFMYCBb/HE+n9ap1qZWSg=; b=DOGMb8rKlM5phS07pK/p5DZoDoApCj/ttRJJifGmwzfXs81Py/Jeir9a+II3GA3ybc gH/uc7ffAfNRHCQa+OB31B4B7To9RAkB58MAP1K46ADqH/H/Xc9vp1GDJShK2yiYrDKt WEF7CoiFSmlUR6SYyzQSZDoUkx11Ve25G84GE= MIME-Version: 1.0 Received: by 10.216.229.200 with SMTP id h50mr1326781weq.32.1314965921857; Fri, 02 Sep 2011 05:18:41 -0700 (PDT) Received: by 10.216.30.135 with HTTP; Fri, 2 Sep 2011 05:18:41 -0700 (PDT) In-Reply-To: <20110901093117.GA15295@openss7.org> References: <20110901093117.GA15295@openss7.org> Date: Fri, 2 Sep 2011 17:48:41 +0530 Message-ID: From: Sandeep Singh To: bidulock@openss7.org, Rajesh Makhija , "sigtran@ietf.org" , "sigtran@ietfa.amsl.com" , "supreet_jain@yahoo.com" Content-Type: multipart/alternative; boundary=0016e6567f98aa00e704abf45cd5 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: Fri, 02 Sep 2011 12:17:27 -0000 --0016e6567f98aa00e704abf45cd5 Content-Type: text/plain; charset=ISO-8859-1 Hi everybody, Thanks for your valuable inputs. It is very clear from *Page 36 of RFC 3331* that the length of Interface Identifier Set having Tag (0x1) can have Length more than 8. According to the following figure, the length should be *(n*4 + 4)* if there are n Interface Identifiers: Please let me know if there is anything wrong in my understanding. Best Regards, Sandeep Singh On Thu, Sep 1, 2011 at 3:01 PM, Brian F. G. Bidulock wrote: > Rajesh, > > I think the diagram on Page 36/RFC 3331 is quite self-explanatory. There > is really only one way to interpret it. > > --brian > > Rajesh Makhija wrote: (Thu, 01 Sep 2011 14:20:47) > > Hello > > > > > > It would be nice to reach a consensus on this matter. Requesting Brian > > and other forum member to share their valuable insights.....on last > > input from Supreet > > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > --0016e6567f98aa00e704abf45cd5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi everybody,=A0=A0

Thanks for your valuable inputs.

It is very clear from Page 36 of RFC 3331 that the length of Interfa= ce=20 Identifier Set having Tag (0x1) can have Length more than 8.

According to the following figure, the length should be (n*4 + 4) if= there are n Interface Identifiers:

3D""
Please let me know if there is anything wrong in my understanding.


Best Regards,

Sandeep Singh


On Thu, Sep 1, 2011 at 3:01 PM, Brian F.= G. Bidulock <= bidulock@openss7.org> wrote:
Rajesh,

I think the diagram on Page 36/RFC 3331 is quite self-explanatory. =A0There=
is really only one way to interpret it.

--brian

Rajesh Makhija wrote: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (Thu, 01 = Sep 2011 14:20:47)
> =A0 =A0Hello
>
>
> =A0 =A0It would be nice to reach a consensus on this matter. Requestin= g Brian
> =A0 =A0and other forum member to share their valuable insights.....on = last
> =A0 =A0input from Supreet
>

--
___________________________________= ____________
Sigtran mailing list
Sigtran@ietf.org
https://www.ietf.org/mailman/listinfo/sigtran

--0016e6567f98aa00e704abf45cd5-- From sandeepsinghmails@gmail.com Fri Sep 2 05:23:34 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 B5BAA21F8D21 for ; Fri, 2 Sep 2011 05:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 HrNVSVVCH79F for ; Fri, 2 Sep 2011 05:23:34 -0700 (PDT) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id B71DF21F8D2B for ; Fri, 2 Sep 2011 05:23:32 -0700 (PDT) Received: by wyh15 with SMTP id 15so2861193wyh.13 for ; Fri, 02 Sep 2011 05:25:06 -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 :content-type; bh=GTd8wsDo/NBoSW3z1+9kMoKYo87ur+xDbTX2Or2LqAE=; b=mUygkchl+fSL7KkD46A8bjm/a9rMlMwHlfXDzTgTBoXe1myQuMNySH7Rj0TWjHmHGr oPxxy8SiC50DlUmbF9EiduPYi+5X3YXFiQ1iW1ufsa65K/5MNIhx6S+fGhFGWG39FTGs wt1wP7KbZsBucULUUWp5WeC+PoBbRb04+eKkY= MIME-Version: 1.0 Received: by 10.216.165.10 with SMTP id d10mr1001099wel.17.1314966306778; Fri, 02 Sep 2011 05:25:06 -0700 (PDT) Received: by 10.216.30.135 with HTTP; Fri, 2 Sep 2011 05:25:06 -0700 (PDT) In-Reply-To: References: <20110901093117.GA15295@openss7.org> Date: Fri, 2 Sep 2011 17:55:06 +0530 Message-ID: From: Sandeep Singh To: bidulock@openss7.org, Rajesh Makhija , "sigtran@ietf.org" , "sigtran@ietfa.amsl.com" , "supreet_jain@yahoo.com" Content-Type: multipart/alternative; boundary=0016e649864e9b6e7b04abf4731d 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: Fri, 02 Sep 2011 12:23:34 -0000 --0016e649864e9b6e7b04abf4731d Content-Type: text/plain; charset=ISO-8859-1 Hi everybody, Thanks for your valuable inputs. It is very clear from *Page 36 of RFC 3331* that the length of Interface Identifier Set having Tag (0x1) can have Length more than 8. According to the following figure, the length should be *(n*4 + 4)* if there are n Interface Identifiers: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xb) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Mode Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1=integer) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Interface Identifiers* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Please let me know if there is anything wrong in my understanding. Best Regards, Sandeep Singh --0016e649864e9b6e7b04abf4731d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 SGkgZXZlcnlib2R5LKCgIDxicj4KPGJyPgpUaGFua3MgZm9yIHlvdXIgdmFsdWFibGUgaW5wdXRz LiA8YnI+Cjxicj4KSXQgaXMgdmVyeSBjbGVhciBmcm9tIDx1PlBhZ2UgMzYgb2YgUkZDIDMzMzE8 L3U+IHRoYXQgdGhlIGxlbmd0aCBvZiBJbnRlcmZhY2UgCklkZW50aWZpZXIgU2V0IGhhdmluZyBU YWcgKDB4MSkgY2FuIGhhdmUgTGVuZ3RoIG1vcmUgdGhhbiA4LiA8YnI+PGJyPgpBY2NvcmRpbmcg dG8gdGhlIGZvbGxvd2luZyBmaWd1cmUsIHRoZSBsZW5ndGggc2hvdWxkIGJlIDxiPihuKjQgKyA0 KTwvYj4gaWYgdGhlcmUgYXJlIG4gSW50ZXJmYWNlIElkZW50aWZpZXJzOjxicj4KPGJyPqCgoCAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1oCA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxPGJyPqCgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rPGJyPqCgIHygoKCgoKCgoKCgIFRhZyAoMHhiKaCgoKCgoKCgoCCgIKAg oCCgIKAgfKCgoKCgoKCgoKCgIExlbmd0aCA9IDigoKCgoKCgIKAgoKAgoCB8PGJyPgqgoCArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzxi cj6goCB8oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIFRyYWZmaWMgTW9kZSBUeXBloKCg oKCgoKCgoKCgoKCgoKCgoKCgoKAgoCCgIKCgIHw8YnI+oKAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8YnI+oKAgfKCgoKAgVGFnICgw eDE9aW50ZWdlcimgoKCgoKCgIKAgoCCgoCB8oKCgoKCgoKCgoKAgTGVuZ3RooKCgoKCgoKCgoKAg oCCgoCCgoCB8PGJyPgqgoCArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKzxicj6goCAvoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAg XDxicj6goCBcoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBJbnRlcmZhY2UgSWRl bnRpZmllcnMqoKCgoKCgoKCgoKCgoCCgIKCgIKCgoKAgLzxicj4KoKAgL6CgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKCgIFw8YnI+oKAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8YnI+Cjxicj4KClBsZWFzZSBsZXQgbWUga25vdyBp ZiB0aGVyZSBpcyBhbnl0aGluZyB3cm9uZyBpbiBteSB1bmRlcnN0YW5kaW5nLiA8YnI+PGJyPgoK PGJyPgpCZXN0IFJlZ2FyZHMsPGJyPjxmb250IGNvbG9yPSIjODg4ODg4Ij4KPGJyPgpTYW5kZWVw IFNpbmdoPC9mb250Pgo= --0016e649864e9b6e7b04abf4731d-- From sandeepsinghmails@gmail.com Fri Sep 2 05:23:34 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 D813321F8D29 for ; Fri, 2 Sep 2011 05:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 OJzJue5U7XQW for ; Fri, 2 Sep 2011 05:23:34 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B60D821F8D2A for ; Fri, 2 Sep 2011 05:23:32 -0700 (PDT) Received: by wyg8 with SMTP id 8so2554146wyg.31 for ; Fri, 02 Sep 2011 05:25:06 -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 :content-type; bh=GTd8wsDo/NBoSW3z1+9kMoKYo87ur+xDbTX2Or2LqAE=; b=mUygkchl+fSL7KkD46A8bjm/a9rMlMwHlfXDzTgTBoXe1myQuMNySH7Rj0TWjHmHGr oPxxy8SiC50DlUmbF9EiduPYi+5X3YXFiQ1iW1ufsa65K/5MNIhx6S+fGhFGWG39FTGs wt1wP7KbZsBucULUUWp5WeC+PoBbRb04+eKkY= MIME-Version: 1.0 Received: by 10.216.165.10 with SMTP id d10mr1001099wel.17.1314966306778; Fri, 02 Sep 2011 05:25:06 -0700 (PDT) Received: by 10.216.30.135 with HTTP; Fri, 2 Sep 2011 05:25:06 -0700 (PDT) In-Reply-To: References: <20110901093117.GA15295@openss7.org> Date: Fri, 2 Sep 2011 17:55:06 +0530 Message-ID: From: Sandeep Singh To: bidulock@openss7.org, Rajesh Makhija , "sigtran@ietf.org" , "sigtran@ietfa.amsl.com" , "supreet_jain@yahoo.com" Content-Type: multipart/alternative; boundary=0016e649864e9b6e7b04abf4731d 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: Fri, 02 Sep 2011 12:23:35 -0000 --0016e649864e9b6e7b04abf4731d Content-Type: text/plain; charset=ISO-8859-1 Hi everybody, Thanks for your valuable inputs. It is very clear from *Page 36 of RFC 3331* that the length of Interface Identifier Set having Tag (0x1) can have Length more than 8. According to the following figure, the length should be *(n*4 + 4)* if there are n Interface Identifiers: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xb) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Mode Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1=integer) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Interface Identifiers* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Please let me know if there is anything wrong in my understanding. Best Regards, Sandeep Singh --0016e649864e9b6e7b04abf4731d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 SGkgZXZlcnlib2R5LKCgIDxicj4KPGJyPgpUaGFua3MgZm9yIHlvdXIgdmFsdWFibGUgaW5wdXRz LiA8YnI+Cjxicj4KSXQgaXMgdmVyeSBjbGVhciBmcm9tIDx1PlBhZ2UgMzYgb2YgUkZDIDMzMzE8 L3U+IHRoYXQgdGhlIGxlbmd0aCBvZiBJbnRlcmZhY2UgCklkZW50aWZpZXIgU2V0IGhhdmluZyBU YWcgKDB4MSkgY2FuIGhhdmUgTGVuZ3RoIG1vcmUgdGhhbiA4LiA8YnI+PGJyPgpBY2NvcmRpbmcg dG8gdGhlIGZvbGxvd2luZyBmaWd1cmUsIHRoZSBsZW5ndGggc2hvdWxkIGJlIDxiPihuKjQgKyA0 KTwvYj4gaWYgdGhlcmUgYXJlIG4gSW50ZXJmYWNlIElkZW50aWZpZXJzOjxicj4KPGJyPqCgoCAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1oCA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxPGJyPqCgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rPGJyPqCgIHygoKCgoKCgoKCgIFRhZyAoMHhiKaCgoKCgoKCgoCCgIKAg oCCgIKAgfKCgoKCgoKCgoKCgIExlbmd0aCA9IDigoKCgoKCgIKAgoKAgoCB8PGJyPgqgoCArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzxi cj6goCB8oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIFRyYWZmaWMgTW9kZSBUeXBloKCg oKCgoKCgoKCgoKCgoKCgoKCgoKAgoCCgIKCgIHw8YnI+oKAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8YnI+oKAgfKCgoKAgVGFnICgw eDE9aW50ZWdlcimgoKCgoKCgIKAgoCCgoCB8oKCgoKCgoKCgoKAgTGVuZ3RooKCgoKCgoKCgoKAg oCCgoCCgoCB8PGJyPgqgoCArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKzxicj6goCAvoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAg XDxicj6goCBcoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBJbnRlcmZhY2UgSWRl bnRpZmllcnMqoKCgoKCgoKCgoKCgoCCgIKCgIKCgoKAgLzxicj4KoKAgL6CgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKCgIFw8YnI+oKAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8YnI+Cjxicj4KClBsZWFzZSBsZXQgbWUga25vdyBp ZiB0aGVyZSBpcyBhbnl0aGluZyB3cm9uZyBpbiBteSB1bmRlcnN0YW5kaW5nLiA8YnI+PGJyPgoK PGJyPgpCZXN0IFJlZ2FyZHMsPGJyPjxmb250IGNvbG9yPSIjODg4ODg4Ij4KPGJyPgpTYW5kZWVw IFNpbmdoPC9mb250Pgo= --0016e649864e9b6e7b04abf4731d-- From bidulock@openss7.org Fri Sep 2 08:37:18 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 3656421F8B51 for ; Fri, 2 Sep 2011 08:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_45=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 2pbaoxekghwC for ; Fri, 2 Sep 2011 08:37:17 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.117.178]) by ietfa.amsl.com (Postfix) with ESMTP id 22F6421F8B08 for ; Fri, 2 Sep 2011 08:37: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 p82Fcigm015159; Fri, 2 Sep 2011 09:38: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 p82Fcit9004802; Fri, 2 Sep 2011 09:38:44 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p82FcfNJ004796; Fri, 2 Sep 2011 09:38:41 -0600 Date: Fri, 2 Sep 2011 09:38:41 -0600 From: "Brian F. G. Bidulock" To: Santhana Message-ID: <20110902153841.GA22015@openss7.org> Mail-Followup-To: Santhana , sigtran@ietf.org References: <6C12A37EC14548A2BA8646F2B772716E@china.huawei.com> <20110902075428.GA14460@openss7.org> <020D83DA676E4E959A65DC172D86EDA5@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <020D83DA676E4E959A65DC172D86EDA5@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] Handling DUNA about Self Point Code 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: Fri, 02 Sep 2011 15:37:18 -0000 Santhana, Santhana wrote: (Fri, 02 Sep 2011 13:53:43) > Hi Brian > I meant SG-ASP mode only and also SG sending DUNA about itself to an > AS. Now it is clear from your reply that we must do this with unsolicited > INACTIVE-ACK or DOWN-ACK from SG to ASP. > > So if such DUNA(about self PC) comes from SG, then the handling > behavior in ASP could be just discarding it right ? Well, no. DUNA received at the ASP (other than DUNA(*)), corresponds to MTP-PAUSE. The ASP should issue MTP-PAUSE corresponding to the DUNA to the MTP-User of the AS at the ASP. The MTP-User of the AS at the ASP should process the MTP-PAUSE just as it always does. Receiving an MTP-PAUSE for any point code is valid for the MTP-User. > I could not understand the below scenario described by you. Can u > explain ? There are several reasons why a detintaion (point code) is unavailable: there is currently no route to the destination, or the destinaion is prohibited from a GWS perspective. A point code on the SG typically always available from a routing perspective (because it is local), with the possible exception of isolation of the NIF (handled by unsolicited ASPDN Ack), but the local destination could be unavailable from an authorization perspective (the MTP-User is not permitted to route MTP messages to itself). That is what I meant by an MTP-User sending an MTP message from itself (e.g. 1-1-1) to itself (1-1-1). This might be quite possible at the SG from a routing (discrimination) perspective but might be prohibited from an authorization perspective. In this case the SG would send DUNA(1-1-1) and would, therefore, be sending a DUNA for one of its own point codes. --brian > " The only case where I can see that an SG would send DUNA for a point > code belonging to an AS to an ASP serving that AS would be where it > is prohibited for an ASP to send a message from a point code > belonging to the AS to another (or the same) point code belonging to > the AS. So, for example, if the AS attempted to send data from > point code 1-1-1 to point code 1-1-1, the SG could reply with > DUNA(1-1-1). Is that what you were meaning?" > > Thanks & regards > Santhana > > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Friday, September 02, 2011 1:24 PM > To: Santhana > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] [M3UA] Handling DUNA about Self Point Code > > Santhana, > > Why would one ever do something like that? > > In IPSP configuration, SNMM are not used (M3UA is point-to-point in > IPSP mode). So, I can only conceive that you mean SG-ASP mode. > > In SG-ASP mode, an ASP signals its unavailability to service an AS > using ASPIA. An ASP sending DUNA for the point code associated with > an AS is not only wrong (other ASPs can still serve the AS), it is > not specified (DUNA is only sent from SG to ASP). So, I don't > suppose that you mean an ASP sending DUNA, but an SG. > > An SG sends DUNA for a specific point code when that point code is > unavailable to the SG. That is, when the routeset from the SG to > the remote point code is transfer-prohibited. Transfer of MTP > messages to a local point code is always available unless the MTP > layer at the SG is unavailable. > > There are two proscribed procedures at the SG for handling > partitioning: when the SG is separated from the SS7 network and > unable to transfer any MTP messages to remote point codes (e.g. > isolation at the NIF) it can send DUNA(*) to indicate the > isolation. This means that the SG cannot send MTP messages to *any* > *remote* point code. You see that DUNA means that MTP messages > cannot be transferred *to* the destination point code. The second > procedure is when the SG is unable to support an AS (local point > code). In this case the SG can send unsolicited ASPIA Ack for the > affected AS to the affected ASPs. When the ASP attempts to > reactivate the AS using ASPAC, it returns ERROR(management blocking) > until the fault clears. When the SG is unable to serve *any* AS, it > an send unsolicited ASPDN Ack, and return ERROR(management blocking) > when the ASP attempts ASPUP until the fault clears. > > The only case where I can see that an SG would send DUNA for a point > code belonging to an AS to an ASP serving that AS would be where it > is prohibited for an ASP to send a message from a point code > belonging to the AS to another (or the same) point code belonging to > the AS. So, for example, if the AS attempted to send data from > point code 1-1-1 to point code 1-1-1, the SG could reply with > DUNA(1-1-1). Is that what you were meaning? > > --brian > > Santhana wrote: (Fri, 02 Sep 2011 08:14:14) > > Hi Brian > > > > In M3UA can an entity send DUNA(about itself), to convey its > > unavailability, for some other Management reasons. > > > > > > If such DUNA(about self Point Code) is received from adjacent > > Point Code, then how to process it ? Can it be processed like normal > > DUNA, and a DAUD procedure be started? > > > > > > Or for management reasons the control should be only at the > > level of Blocking the ASP? > > > > > > Pls share your opinion. > > > > > > Regards > > > > Santhana > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > > _______________________________________________ > 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 Fri Sep 2 08:50:26 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 1771D21F8BAB for ; Fri, 2 Sep 2011 08:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, MIME_8BIT_HEADER=0.3] 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 dLDfec4qghXe for ; Fri, 2 Sep 2011 08:50:25 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.117.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2631A21F8BA0 for ; Fri, 2 Sep 2011 08:50: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 p82Fq0c3015222; Fri, 2 Sep 2011 09:52: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 p82Fq0uW006754; Fri, 2 Sep 2011 09:52:00 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p82Fpx6D006753; Fri, 2 Sep 2011 09:51:59 -0600 Date: Fri, 2 Sep 2011 09:51:59 -0600 From: "Brian F. G. Bidulock" To: Mikhail Plotkin Message-ID: <20110902155159.GB22015@openss7.org> Mail-Followup-To: Mikhail Plotkin , sigtran@ietf.org References: <81059a00bf504529899e311fa7954479bcbc25b1@mail.qip.ru> 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] =?iso-8859-1?q?SCON_received_a=ADt_ASP_from_one_of_SGs?= 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: Fri, 02 Sep 2011 15:50:26 -0000 Mikhail, Mikhail Plotkin wrote: (Fri, 02 Sep 2011 14:10:41) > Sorry for the previous mail, there was something with the format. > > Hi All, > > Hope to get a piece of advise regarding interpretation of > > sections 1.3.2 and 4.5.2.2 of RFC4666. > > > > ASP has routes to SS7 destination point through several SGs. > > > > 1 . If ASP gets SCON from one of SGs should it immediately send > > congestion indication to the user or should we send report to the > > user if and only if SCON received from both SGs? RFC says that > > ASP "determines whether or not the overall availability or > > congestion status of the affected destination(s) has changed". > > Does it mean ASP should set for the destination the minimum > > congestion status among all SGs or the maximum congestion status > > among all SGs ? In the multiple SG as STP configuration, the SCON received at an ASP is roughly equivalent to a TFC. TFC is used to signal congestion of a routeset somewhere along the path to the destination. The direction from which it arrives is of no consequence. So, yes, if the SCON is received at the ASP, the M3UA layer should issue the corresponding MTP-STATUS message indicating PC congestion and the congestion level to the MTP-User for the AS. There is no need to go messing with the congestion level, if the load is so imbalanced, the higher level messages will still throttle the MTP-User behaviour. > > 2. In the same configuration. If we get SCON from one SG should > > we try to redistribute the part of traffic from the congested > > route, that leads to congestion, to the other routes through > > which this destination is accessible? No, definitely not. SS7 does not redistribute directly on the basis of congestion. In ANSI/2000 procedures there is a mechianism for issuing a TFR (DRST) from an STP (SG) when there is a 'danger of congestion', but these procedure provide proper hysteresis to avoid thrashing. It is sufficent that the ASP process received DRST correctly, and it should never reroute on SCON. The SCON could have been triggered by congestion (and TFC) quite remote from the SGs in the SS7 network. Which SG it came through is of no consequence. An SG which discovers local congestion (or danger of congestion caused by changeovers to under-provisioned C-links) can request the AS to reroute traffic using the TFR (DRST) procedures. --brian > > > > If yes, what measures can be taken to diminish possible negative > > side effects of such redistribution? By the way, RFC recommends > > to handle it "much like an MTP3 layer maintains route-set > > status", but ITU-T Q.704 does not say anything about rerouting > > caused by congestion in one of the routes. > > > > (Similar questions have been discussed here before, but those > > were for several ASPs and a single SG) > > > Regards, Mikhail. -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From deepak.gunjal@aricent.com Sun Sep 4 12:03:42 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 78C2221F8610 for ; Sun, 4 Sep 2011 12:03:42 -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 wx9JvWuWrCDv for ; Sun, 4 Sep 2011 12:03:41 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0E43221F8726 for ; Sun, 4 Sep 2011 12:03:41 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id C8ADE36BAE for ; Mon, 5 Sep 2011 00:29:53 +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 B305736B89 for ; Mon, 5 Sep 2011 00:29:53 +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, 5 Sep 2011 00:35:20 +0530 From: Deepak Gunjal To: "sigtran@ietf.org" Date: Mon, 5 Sep 2011 00:35:15 +0530 Thread-Topic: Needs clarification on handling of SCON message Thread-Index: AcxrNZR7g37fos+KSPGf7fbCZ7F+PA== Message-ID: <233DCD84F0DD4C4BA6376E8D12567A8E3510CAC3F2@GUREXMB01.ASIAN.AD.ARICENT.COM> 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_233DCD84F0DD4C4BA6376E8D12567A8E3510CAC3F2GUREXMB01ASIA_" MIME-Version: 1.0 Subject: [Sigtran] Needs clarification on handling of SCON message 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, 04 Sep 2011 19:03:42 -0000 --_000_233DCD84F0DD4C4BA6376E8D12567A8E3510CAC3F2GUREXMB01ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have one query regarding the SCON message handling between SG and ASP. Suppose a SG informs one of the Active ASP serving an AS that one of the po= int code in MTP3 network has become congested and hence sends the SCON mess= age with congestion level say 1 to ASP. After receiving the SCON message with congestion level 1, the ASP starts th= e audit procedure and starts sending the DAUD message for that destination. Now when the destination point code in MTP3 network become uncongested, can= a SGP inform the ASP by sending a DAVA message or it always informs by sen= ding SCON message with congestion level as 0. And what if say after sending the initial SCON message to ASP with congesti= on level 1, the SG gets restarted. After restart would it be a DAVA message= sent to ASP, on receiving it the ASP clears the congestion level set earli= er and marks the destination point available and informs the higher layers. Regards Deepak =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=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_233DCD84F0DD4C4BA6376E8D12567A8E3510CAC3F2GUREXMB01ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have one query regarding the SCON message handling= between SG and ASP.

 

Suppose a SG informs one of the Active ASP serving a= n AS that one of the point code in MTP3 network has become congested and he= nce sends the SCON message with congestion level say 1 to ASP.

 

After receiving the SCON message with congestion lev= el 1, the ASP starts the audit procedure and starts sending the DAUD messag= e for that destination.

 

Now when the destination point code in MTP3 network = become uncongested, can a SGP inform the ASP by sending a DAVA message or i= t always informs by sending SCON message with congestion level as 0.

 

And what if say after sending the initial SCON messa= ge to ASP with congestion level 1, the SG gets restarted. After restart wou= ld it be a DAVA message sent to ASP, on receiving it the ASP clears the con= gestion level set earlier and marks the destination point available and informs the higher layers.<= /p>

 

Regards

Deepak





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=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_233DCD84F0DD4C4BA6376E8D12567A8E3510CAC3F2GUREXMB01ASIA_-- From snemana@sonusnet.com Mon Sep 5 00:58: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 2490121F8B08 for ; Mon, 5 Sep 2011 00:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=1.205, 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 RwG+1TdnOH3e for ; Mon, 5 Sep 2011 00:58:20 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBCC21F8B06 for ; Mon, 5 Sep 2011 00:58:20 -0700 (PDT) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p8580Pus002870; Mon, 5 Sep 2011 04:00:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6BA1.CCEAC92C" Date: Mon, 5 Sep 2011 04:00:25 -0400 Message-ID: In-Reply-To: <233DCD84F0DD4C4BA6376E8D12567A8E3510CAC3F2@GUREXMB01.ASIAN.AD.ARICENT.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] Needs clarification on handling of SCON message Thread-Index: AcxrNZR7g37fos+KSPGf7fbCZ7F+PAAabCsg References: <233DCD84F0DD4C4BA6376E8D12567A8E3510CAC3F2@GUREXMB01.ASIAN.AD.ARICENT.COM> From: "Nemana, Satya" To: "Deepak Gunjal" , Subject: Re: [Sigtran] Needs clarification on handling of SCON message 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, 05 Sep 2011 07:58:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6BA1.CCEAC92C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Deepak, =20 RFC 4666 Section 4.5.3 The SGP SHOULD respond to a DAUD message with the MTP3 availability/congestion status of the routeset associated with each Destination Point Codes in the DAUD message. The status of each SS7 destination requested is indicated in a DUNA message (if unavailable), a DAVA message (if available), or a DRST (if restricted and the SGP supports this feature in national networks). For national networks, the SGP SHOULD additionally respond with a SCON message (if the destination is congested) before the DAVA or DRST. =20 So, SGP should always send DUNA/DAVA/DRST and SCON. If there is no congestion, the level should be 0 in the SCON. =20 After SGP restart, I would expect the SGP to clear all the SS7 node status to available and not congested as per standard MTP procedures. If there are TFC messages from the SS7 network to the SGP indicating the remote node is still congested (1/2/3) the SGP should once again broadcast SCON and respond to DAUD accordingly with DRST/DAVA and SCON. If the ASP had cleared the status to Unavailable/Un-congested when the SGP was down, it should now update the status again with the received DUNA/DRST/DAVA and SCON messages from the SGP. =20 As per 4.5 (MTP Restart), SCON "can" be sent by the SGP on restart. =20 Regards, Satya =20 ________________________________ From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Deepak Gunjal Sent: 04 September 2011 20:05 To: sigtran@ietf.org Subject: [Sigtran] Needs clarification on handling of SCON message =20 Hi, =20 I have one query regarding the SCON message handling between SG and ASP. =20 Suppose a SG informs one of the Active ASP serving an AS that one of the point code in MTP3 network has become congested and hence sends the SCON message with congestion level say 1 to ASP. =20 After receiving the SCON message with congestion level 1, the ASP starts the audit procedure and starts sending the DAUD message for that destination. =20 Now when the destination point code in MTP3 network become uncongested, can a SGP inform the ASP by sending a DAVA message or it always informs by sending SCON message with congestion level as 0. =20 And what if say after sending the initial SCON message to ASP with congestion level 1, the SG gets restarted. After restart would it be a DAVA message sent to ASP, on receiving it the ASP clears the congestion level set earlier and marks the destination point available and informs the higher layers. =20 Regards Deepak =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=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 ------_=_NextPart_001_01CC6BA1.CCEAC92C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Deepak,

=

 

RFC 4666 Section = 4.5.3

<snip>

The SGP SHOULD respond to a DAUD = message with the MTP3    availability/congestion status of the = routeset associated with each    Destination Point Codes in the = DAUD message.  The status of each SS7    destination = requested is indicated in a DUNA message (if    unavailable), a = DAVA message (if available), or a DRST (if restricted    and = the SGP supports this feature in national networks).  For =    national networks, the SGP SHOULD additionally respond with a SCON =    message (if the destination is congested) before the DAVA or = DRST.

<snip>

 

So, SGP should always send = DUNA/DAVA/DRST and SCON.

If there is no congestion, the = level should be 0 in the SCON.

 

After SGP restart, I would expect = the SGP to clear all the SS7 node status to available and not congested as per = standard MTP procedures.

If there are TFC messages from the = SS7 network to the SGP indicating the remote node is still congested (1/2/3) = the SGP should once again broadcast SCON and respond to DAUD accordingly = with DRST/DAVA and SCON.

If the ASP had cleared the status = to Unavailable/Un-congested when the SGP was down, it should now update the = status again with the received DUNA/DRST/DAVA and SCON messages from the = SGP.

 

As per 4.5 (MTP Restart), SCON = “can” be sent by the SGP on restart.

 

Regards,

Satya

 


From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Deepak Gunjal
Sent: 04 September 2011 = 20:05
To: sigtran@ietf.org
Subject: [Sigtran] Needs clarification on handling of SCON message

 

Hi,

 

I have one query regarding the SCON message handling between SG = and ASP.

 

Suppose a SG informs one of the Active ASP serving an AS that = one of the point code in MTP3 network has become congested and hence sends the = SCON message with congestion level say 1 to ASP.

 

After receiving the SCON message with congestion level 1, the = ASP starts the audit procedure and starts sending the DAUD message for that destination.

 

Now when the destination point code in MTP3 network become = uncongested, can a SGP inform the ASP by sending a DAVA message or it always informs = by sending SCON message with congestion level as = 0.

 

And what if say after sending the initial SCON message to ASP = with congestion level 1, the SG gets restarted. After restart would it be a = DAVA message sent to ASP, on receiving it the ASP clears the congestion level = set earlier and marks the destination point available and informs the higher layers.

 

Regards

Deepak





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=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

------_=_NextPart_001_01CC6BA1.CCEAC92C-- From David.Laight@ACULAB.COM Mon Sep 5 02:21:29 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 BEB9B21F857D for ; Mon, 5 Sep 2011 02:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, MIME_QP_LONG_LINE=1.396] 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 cT2gFDqzmSFh for ; Mon, 5 Sep 2011 02:21:29 -0700 (PDT) Received: from mx0.aculab.com (mx0.aculab.com [213.249.233.131]) by ietfa.amsl.com (Postfix) with SMTP id 32B5F21F8569 for ; Mon, 5 Sep 2011 02:21:27 -0700 (PDT) Received: (qmail 20178 invoked from network); 5 Sep 2011 09:23:07 -0000 Received: from localhost (127.0.0.1) by mx0.aculab.com with SMTP; 5 Sep 2011 09:23:07 -0000 Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 20085-01 for ; Mon, 5 Sep 2011 10:23:05 +0100 (BST) Received: (qmail 20103 invoked by uid 599); 5 Sep 2011 09:23:05 -0000 Received: from unknown (HELO saturn3.Aculab.com) (10.202.163.5) by mx0.aculab.com (qpsmtpd/0.28) with ESMTP; Mon, 05 Sep 2011 10:23:05 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6BAD.5A850531" Date: Mon, 5 Sep 2011 10:22:37 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Sigtran] Interface Identifier in ASPTM message in M2UA thread-index: Acxpa176W0dMp6X0SfSBA3RbWRCMKQCQPDVA From: "David Laight" To: "Sandeep Singh" , , "Rajesh Makhija" , , , X-Virus-Scanned: by iCritical at mx0.aculab.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, 05 Sep 2011 09:21:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6BAD.5A850531 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My thoughts on this are that there is really no point in trying to put requests for multiple interfaces interfaces into a single message. =20 All it does is make the code more complex and might lead to interworking issues - at best it will be exercising little-used code paths. =20 It might appear to be useful in order to reduce the number of message sent, but the number is small compared to what is likely to happen when the links are in use. In theory the multiple requests can be transferred in a single ethernet packet - which will get most of the benefits. =20 And, if any of the Interface identifiers are invalid, any error reporting is somewhat easier... =20 David ________________________________ From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Sandeep Singh Sent: 02 September 2011 13:25 To: bidulock@openss7.org; Rajesh Makhija; sigtran@ietf.org; sigtran@ietfa.amsl.com; supreet_jain@yahoo.com Subject: Re: [Sigtran] Interface Identifier in ASPTM message in M2UA =09 =09 Hi everybody, =20 =09 Thanks for your valuable inputs.=20 =09 It is very clear from Page 36 of RFC 3331 that the length of Interface Identifier Set having Tag (0x1) can have Length more than 8.=20 =09 According to the following figure, the length should be (n*4 + 4) if there are n Interface Identifiers: =09 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xb) | Length =3D 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Mode Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1=3Dinteger) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Interface Identifiers* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 Please let me know if there is anything wrong in my understanding.=20 =09 =09 Best Regards, =09 Sandeep Singh=20 =0D=0A =0D= ------_=_NextPart_001_01CC6BAD.5A850531 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
My thoughts on this are that there is really = no point=20 in trying to put requests
for multiple interfaces interfaces into a = single=20 message.
 
All it does is make the code more complex and = might=20 lead to interworking
issues - at best it will be exercising = little-used code=20 paths.
 
It might appear to be useful in order to = reduce the=20 number of message sent,
but the number is small compared to what is = likely to=20 happen when
the links are in use.
In theory the multiple requests can be = transferred in a=20 single ethernet
packet - which will get most of the=20 benefits.
 
And, if any of the Interface identifiers are = invalid,=20 any error reporting
is somewhat easier...
 
    = David


From: sigtran-bounces@ietf.org=20 [mailto:sigtran-bounces@ietf.org] On Behalf Of Sandeep=20 Singh
Sent: 02 September 2011 13:25
To:=20 bidulock@openss7.org; Rajesh Makhija; sigtran@ietf.org;=20 sigtran@ietfa.amsl.com; supreet_jain@yahoo.com
Subject: Re:=20 [Sigtran] Interface Identifier in ASPTM message in = M2UA

Hi everybody,  

Thanks for your valuable = inputs.=20

It is very clear from Page 36 of RFC 3331 that the = length of=20 Interface Identifier Set having Tag (0x1) can have Length more than 8. =

According to the following figure, the length should be = (n*4 +=20 4) if there are n Interface Identifiers:

    = 0 1 2 3=20 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
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 &nbs= p;=20 |           Tag=20 (0xb)            =  =20      =20 |            = Length =3D=20 8               = |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 &nbs= p;=20 = |            =             &= nbsp;     =20 Traffic Mode=20 = Type           &nb= sp;           =20        |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 &nbs= p;=20 |     Tag=20 (0x1=3Dinteger)          =  =20   =20 |           =20 = Length            =         |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 &nbs= p;=20 = /            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =  =20 \
  =20 = \            =             &= nbsp;         =20 Interface=20 = Identifiers*          &= nbsp;  =20           /
  =20 = /            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;=20                     =  =20    \
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Please= let=20 me know if there is anything wrong in my understanding. =


Best=20 Regards,

Sandeep Singh
=20
= =0D=0A
Registered Address Lakeside, Br= amley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 13973= 86 (Wales)
=0D=0A
=0D=0A

P Please consider the environment and d= on't print this e-mail unless you really need to

<= /FONT>

= ------_=_NextPart_001_01CC6BAD.5A850531-- From David.Laight@ACULAB.COM Mon Sep 5 02:21: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 6812521F84F6 for ; Mon, 5 Sep 2011 02:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, MIME_QP_LONG_LINE=1.396] 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 E1gQgLmznJU6 for ; Mon, 5 Sep 2011 02:21:36 -0700 (PDT) Received: from mx0.aculab.com (mx0.aculab.com [213.249.233.131]) by ietfa.amsl.com (Postfix) with SMTP id 6142D21F8B13 for ; Mon, 5 Sep 2011 02:21:35 -0700 (PDT) Received: (qmail 20214 invoked from network); 5 Sep 2011 09:23:10 -0000 Received: from localhost (127.0.0.1) by mx0.aculab.com with SMTP; 5 Sep 2011 09:23:10 -0000 Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 13580-06 for ; Mon, 5 Sep 2011 10:23:05 +0100 (BST) Received: (qmail 20103 invoked by uid 599); 5 Sep 2011 09:23:05 -0000 Received: from unknown (HELO saturn3.Aculab.com) (10.202.163.5) by mx0.aculab.com (qpsmtpd/0.28) with ESMTP; Mon, 05 Sep 2011 10:23:05 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6BAD.5A850531" Date: Mon, 5 Sep 2011 10:22:37 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Sigtran] Interface Identifier in ASPTM message in M2UA thread-index: Acxpa176W0dMp6X0SfSBA3RbWRCMKQCQPDVA From: "David Laight" To: "Sandeep Singh" , , "Rajesh Makhija" , , , X-Virus-Scanned: by iCritical at mx0.aculab.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, 05 Sep 2011 09:21:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6BAD.5A850531 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My thoughts on this are that there is really no point in trying to put requests for multiple interfaces interfaces into a single message. =20 All it does is make the code more complex and might lead to interworking issues - at best it will be exercising little-used code paths. =20 It might appear to be useful in order to reduce the number of message sent, but the number is small compared to what is likely to happen when the links are in use. In theory the multiple requests can be transferred in a single ethernet packet - which will get most of the benefits. =20 And, if any of the Interface identifiers are invalid, any error reporting is somewhat easier... =20 David ________________________________ From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Sandeep Singh Sent: 02 September 2011 13:25 To: bidulock@openss7.org; Rajesh Makhija; sigtran@ietf.org; sigtran@ietfa.amsl.com; supreet_jain@yahoo.com Subject: Re: [Sigtran] Interface Identifier in ASPTM message in M2UA =09 =09 Hi everybody, =20 =09 Thanks for your valuable inputs.=20 =09 It is very clear from Page 36 of RFC 3331 that the length of Interface Identifier Set having Tag (0x1) can have Length more than 8.=20 =09 According to the following figure, the length should be (n*4 + 4) if there are n Interface Identifiers: =09 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xb) | Length =3D 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Mode Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1=3Dinteger) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Interface Identifiers* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 Please let me know if there is anything wrong in my understanding.=20 =09 =09 Best Regards, =09 Sandeep Singh=20 =0D=0A =0D= ------_=_NextPart_001_01CC6BAD.5A850531 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
My thoughts on this are that there is really = no point=20 in trying to put requests
for multiple interfaces interfaces into a = single=20 message.
 
All it does is make the code more complex and = might=20 lead to interworking
issues - at best it will be exercising = little-used code=20 paths.
 
It might appear to be useful in order to = reduce the=20 number of message sent,
but the number is small compared to what is = likely to=20 happen when
the links are in use.
In theory the multiple requests can be = transferred in a=20 single ethernet
packet - which will get most of the=20 benefits.
 
And, if any of the Interface identifiers are = invalid,=20 any error reporting
is somewhat easier...
 
    = David


From: sigtran-bounces@ietf.org=20 [mailto:sigtran-bounces@ietf.org] On Behalf Of Sandeep=20 Singh
Sent: 02 September 2011 13:25
To:=20 bidulock@openss7.org; Rajesh Makhija; sigtran@ietf.org;=20 sigtran@ietfa.amsl.com; supreet_jain@yahoo.com
Subject: Re:=20 [Sigtran] Interface Identifier in ASPTM message in = M2UA

Hi everybody,  

Thanks for your valuable = inputs.=20

It is very clear from Page 36 of RFC 3331 that the = length of=20 Interface Identifier Set having Tag (0x1) can have Length more than 8. =

According to the following figure, the length should be = (n*4 +=20 4) if there are n Interface Identifiers:

    = 0 1 2 3=20 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
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 &nbs= p;=20 |           Tag=20 (0xb)            =  =20      =20 |            = Length =3D=20 8               = |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 &nbs= p;=20 = |            =             &= nbsp;     =20 Traffic Mode=20 = Type           &nb= sp;           =20        |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 &nbs= p;=20 |     Tag=20 (0x1=3Dinteger)          =  =20   =20 |           =20 = Length            =         |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 &nbs= p;=20 = /            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =  =20 \
  =20 = \            =             &= nbsp;         =20 Interface=20 = Identifiers*          &= nbsp;  =20           /
  =20 = /            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;=20                     =  =20    \
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Please= let=20 me know if there is anything wrong in my understanding. =


Best=20 Regards,

Sandeep Singh
=20
= =0D=0A
Registered Address Lakeside, Br= amley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 13973= 86 (Wales)
=0D=0A
=0D=0A

P Please consider the environment and d= on't print this e-mail unless you really need to

<= /FONT>

= ------_=_NextPart_001_01CC6BAD.5A850531-- From rajangam.subramanian@wipro.com Wed Sep 7 01:46:13 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 F208621F86DD for ; Wed, 7 Sep 2011 01:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[AWL=-0.405, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] 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 TzvicHO4C503 for ; Wed, 7 Sep 2011 01:46:12 -0700 (PDT) Received: from wipro-chn-out02.wipro.com (wipro-chn-out02.wipro.com [203.91.208.7]) by ietfa.amsl.com (Postfix) with ESMTP id 4A62B21F86D0 for ; Wed, 7 Sep 2011 01:46:10 -0700 (PDT) X-AuditID: cb5bdd89-b7c00ae000005a38-19-4e672fbd555c Received: from chn-snr-aa01.wipro.com ( [10.145.50.41]) by wipro-chn-out02.wipro.com (Symantec Mail Security) with SMTP id 34.F3.23096.DBF276E4; Wed, 7 Sep 2011 14:17:57 +0530 (IST) Received: from chn-snr-bh2.wipro.com ([10.145.50.92]) by chn-snr-aa01.wipro.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Sep 2011 14:17:58 +0530 Received: from CHN-SNR-MBX03.wipro.com ([10.145.50.194]) by chn-snr-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Sep 2011 14:17:57 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6D3A.D71112FE" Date: Wed, 7 Sep 2011 14:18:41 +0530 Message-ID: <774B5A31E820C94DB1CEA7B809C399B5040389E7@CHN-SNR-MBX03.wipro.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] Interface Identifier in ASPTM message in M2UA Thread-Index: Acxpa22vA9C781S/QX+DPApnCphYHADzbwng References: <20110901093117.GA15295@openss7.org> From: To: , , , , , X-OriginalArrivalTime: 07 Sep 2011 08:47:57.0564 (UTC) FILETIME=[D75D2BC0:01CC6D3A] X-Brightmail-Tracker: AAAAAQAAAZE= 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: Wed, 07 Sep 2011 08:46:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6D3A.D71112FE Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hello Sandeep Singh and all, I differ from your inference of the section 3.3.2.7 (Page 36 RFC 3331). It would be in conflict to section 3.2 (Page 22 of RFC 3331) which actually defines the structure of the Interface Identifier. Section 3.3.2.7 gives an indication of the possible parameters in the ASPAC message but does not define the structure of the parameters (Of course there is an ambiguity in the RFC or rather error, wherein in section 3.2 indicates M2UA specific headers are used only with MAUP messages while they are used also with other messages like ASPSM messages). So from the structure of the Integer Interface Identifier we need to follow section 3.2 which clearly states the length value cannot be greater than 8. Regards, Rajangam ________________________________ From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Sandeep Singh Sent: Friday, September 02, 2011 5:55 PM To: bidulock@openss7.org; Rajesh Makhija; sigtran@ietf.org; sigtran@ietfa.amsl.com; supreet_jain@yahoo.com Subject: Re: [Sigtran] Interface Identifier in ASPTM message in M2UA Hi everybody, Thanks for your valuable inputs. It is very clear from Page 36 of RFC 3331 that the length of Interface Identifier Set having Tag (0x1) can have Length more than 8. According to the following figure, the length should be (n*4 + 4) if there are n Interface Identifiers: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xb) | Length =3D 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Mode Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1=3Dinteger) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Interface Identifiers* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Please let me know if there is anything wrong in my understanding. Best Regards, Sandeep Singh Please do not print this email unless it is absolutely necessary. =0A= =0A= The information contained in this electronic message and any attachments to= this message are intended for the exclusive use of the addressee(s) and may= contain proprietary, confidential or privileged information. If you are not= the intended recipient, you should not disseminate, distribute or copy this= e-mail. Please notify the sender immediately and destroy all copies of this= message and any attachments. =0A= =0A= WARNING: Computer viruses can be transmitted via email. The recipient should= check this email and any attachments for the presence of viruses. The compa= ny accepts no liability for any damage caused by any virus transmitted by th= is email. =0A= =0A= www.wipro.com ------_=_NextPart_001_01CC6D3A.D71112FE Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Hello Sandeep Singh and all,=

   I differ from your inferen= ce of the section 3.3.2.7 (Page 36 RFC 3331). It would be in conflict to sectio= n 3.2 (Page 22 of RFC 3331) which actually defines the structure of the Interf= ace Identifier. Section 3.3.2.7 gives an indication of the possible parameters i= n the ASPAC message but does not define the structure of the parameters (Of course there is an ambiguity in the RFC or rather error, wherein in section= 3.2 indicates M2UA specific headers are used only with MAUP messages while they= are used also with other messages like ASPSM messages).=

 

So from the structure of the Integer Interface Identifier we need to follow section 3.2 which clearly states the length value cannot be greater than 8.

 

Regards,

Rajangam

 


From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Sandeep Singh
Sent: Friday, September 02, 2= 011 5:55 PM
To: bidulock@openss7.org; Raj= esh Makhija; sigtran@ietf.org; sigtran@ietfa.amsl.com; supreet_jain@yahoo.com Subject: Re: [Sigtran] Interf= ace Identifier in ASPTM message in M2UA

 

Hi everybody,  

Thanks for your valuable inputs.

It is very clear from Page 36 of RFC 3331 that the length of Interfac= e Identifier Set having Tag (0x1) can have Length more than 8.

According to the following figure, the length should be (n*4 + 4) if there are n Interface Identifiers:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           T= ag (0xb)                    |            Length = =3D 8               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            &nb= sp;            &= nbsp;     Traffic Mode Type          = ;            &nb= sp;        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Tag (0x1=3Dinteger)               |            Length            &nb= sp;       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /            &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;           \
   \            &nb= sp;            &= nbsp;         Interface Identifiers*         =                /
   /            &nb= sp;            &= nbsp;            = ;            &nb= sp;                                    \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Please let me know if there is anything wrong in my understanding.


Best Regards,

Sandeep Singh

Please do not print this email unl= ess it is absolutely necessary.

=0A= =0A= =0A=

The information contained in this electronic message and any attachments= to this message are intended for the exclusive use of the addressee(s) and= may contain proprietary, confidential or privileged information. If you are= not the intended recipient, you should not disseminate, distribute or copy= this e-mail. Please notify the sender immediately and destroy all copies of= this message and any attachments.

=0A= =0A=

WARNING: Computer viruses can be transmitted via email. The recipient sho= uld check this email and any attachments for the presence of viruses. The co= mpany accepts no liability for any damage caused by any virus transmitted by= this email.

=0A=

=0A= www.wipro.com=0A=

------_=_NextPart_001_01CC6D3A.D71112FE-- From rajangam.subramanian@wipro.com Wed Sep 7 01:56: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 EE29421F8B50 for ; Wed, 7 Sep 2011 01:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] 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 w344SUddL0Yr for ; Wed, 7 Sep 2011 01:56:27 -0700 (PDT) Received: from wipro-chn-out01.wipro.com (wipro-chn-out01.wipro.com [203.91.208.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5588B21F8B35 for ; Wed, 7 Sep 2011 01:56:26 -0700 (PDT) X-AuditID: cb5bdd88-b7cc2ae0000059b6-97-4e672fbd187e Received: from chn-snr-aa01.wipro.com ( [10.145.50.41]) by wipro-chn-out01.wipro.com (Symantec Mail Security) with SMTP id 9F.94.22966.DBF276E4; Wed, 7 Sep 2011 14:17:57 +0530 (IST) Received: from chn-snr-bh2.wipro.com ([10.145.50.92]) by chn-snr-aa01.wipro.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Sep 2011 14:17:58 +0530 Received: from CHN-SNR-MBX03.wipro.com ([10.145.50.194]) by chn-snr-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Sep 2011 14:17:57 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6D3A.D71112FE" Date: Wed, 7 Sep 2011 14:18:41 +0530 Message-ID: <774B5A31E820C94DB1CEA7B809C399B5040389E7@CHN-SNR-MBX03.wipro.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] Interface Identifier in ASPTM message in M2UA Thread-Index: Acxpa22vA9C781S/QX+DPApnCphYHADzbwng References: <20110901093117.GA15295@openss7.org> From: To: , , , , , X-OriginalArrivalTime: 07 Sep 2011 08:47:57.0564 (UTC) FILETIME=[D75D2BC0:01CC6D3A] X-Brightmail-Tracker: AAAAAA== 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: Wed, 07 Sep 2011 08:56:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6D3A.D71112FE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Sandeep Singh and all, I differ from your inference of the section 3.3.2.7 (Page 36 RFC 3331). It would be in conflict to section 3.2 (Page 22 of RFC 3331) which actually defines the structure of the Interface Identifier. Section 3.3.2.7 gives an indication of the possible parameters in the ASPAC message but does not define the structure of the parameters (Of course there is an ambiguity in the RFC or rather error, wherein in section 3.2 indicates M2UA specific headers are used only with MAUP messages while they are used also with other messages like ASPSM messages). =20 So from the structure of the Integer Interface Identifier we need to follow section 3.2 which clearly states the length value cannot be greater than 8. =20 Regards, Rajangam=20 =20 ________________________________ From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Sandeep Singh Sent: Friday, September 02, 2011 5:55 PM To: bidulock@openss7.org; Rajesh Makhija; sigtran@ietf.org; sigtran@ietfa.amsl.com; supreet_jain@yahoo.com Subject: Re: [Sigtran] Interface Identifier in ASPTM message in M2UA =20 Hi everybody, =20 Thanks for your valuable inputs.=20 It is very clear from Page 36 of RFC 3331 that the length of Interface Identifier Set having Tag (0x1) can have Length more than 8.=20 According to the following figure, the length should be (n*4 + 4) if there are n Interface Identifiers: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xb) | Length =3D 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Mode Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1=3Dinteger) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Interface Identifiers* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Please let me know if there is anything wrong in my understanding.=20 Best Regards, Sandeep Singh=20 ------_=_NextPart_001_01CC6D3A.D71112FE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Sandeep Singh and = all,

   I differ from your = inference of the section 3.3.2.7 (Page 36 RFC 3331). It would be in conflict to = section 3.2 (Page 22 of RFC 3331) which actually defines the structure of the = Interface Identifier. Section 3.3.2.7 gives an indication of the possible = parameters in the ASPAC message but does not define the structure of the parameters = (Of course there is an ambiguity in the RFC or rather error, wherein in = section 3.2 indicates M2UA specific headers are used only with MAUP messages while = they are used also with other messages like ASPSM = messages).

 

So from the structure of the = Integer Interface Identifier we need to follow section 3.2 which clearly states = the length value cannot be greater than 8.

 

Regards,

Rajangam =

 


From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Sandeep Singh
Sent: Friday, September = 02, 2011 5:55 PM
To: bidulock@openss7.org; = Rajesh Makhija; sigtran@ietf.org; sigtran@ietfa.amsl.com; = supreet_jain@yahoo.com
Subject: Re: [Sigtran] = Interface Identifier in ASPTM message in M2UA

 

Hi everybody,  

Thanks for your valuable inputs.

It is very clear from Page 36 of RFC 3331 that the length of = Interface Identifier Set having Tag (0x1) can have Length more than 8.

According to the following figure, the length should be (n*4 + 4) if there are n Interface Identifiers:

    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
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   = |           Tag (0xb)            =         |            = Length =3D 8               |
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            =             &= nbsp;      Traffic Mode = Type           &nb= sp;                   |
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Tag (0x1=3Dinteger)               |            Length            =         |
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =   \
   \            =             &= nbsp;          Interface = Identifiers*          &= nbsp;             /
   /            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;                     =      \
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Please let me know if there is anything wrong in my understanding.


Best Regards,

Sandeep Singh

------_=_NextPart_001_01CC6D3A.D71112FE-- From bidulock@openss7.org Wed Sep 7 02:15:03 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 D545D21F8515 for ; Wed, 7 Sep 2011 02:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 pqDcY50Hrvqn for ; Wed, 7 Sep 2011 02:15:03 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.117.178]) by ietfa.amsl.com (Postfix) with ESMTP id C80F021F84F9 for ; Wed, 7 Sep 2011 02:15:02 -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 p879Gd9C013798; Wed, 7 Sep 2011 03:16:39 -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 p879GcjR019627; Wed, 7 Sep 2011 03:16:38 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p879Gbp9019626; Wed, 7 Sep 2011 03:16:37 -0600 Date: Wed, 7 Sep 2011 03:16:37 -0600 From: "Brian F. G. Bidulock" To: rajangam.subramanian@wipro.com Message-ID: <20110907091637.GA17415@openss7.org> Mail-Followup-To: rajangam.subramanian@wipro.com, sandeepsinghmails@gmail.com, rajesh.makhija@aricent.com, sigtran@ietf.org, sigtran@ietfa.amsl.com, supreet_jain@yahoo.com References: <774B5A31E820C94DB1CEA7B809C399B5040389E7@CHN-SNR-MBX03.wipro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <774B5A31E820C94DB1CEA7B809C399B5040389E7@CHN-SNR-MBX03.wipro.com> 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, rajesh.makhija@aricent.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: Wed, 07 Sep 2011 09:15:03 -0000 rajangam.subramanian, Well, no. 3.2 applies to MAUP messages only. MAUP messages are specific to an interface. MAUP messages control the MTP2 signalling link and therefore must identify a specific signalling link. Therefore, the Integer IID can only identify a single signalling link for MAUP messages and the length needs to be 8. Note also that, although text IIDs are also supported, IID ranges are not. ASPTM messages, OTOH, specify a group of IIDs that belong to an AS. An AS can consist of more than one signalling link. (See 1.5.1: "An AS MAY support more than one Interface Identifier.") Therefore, the ASPAC and ASPAC Ack messages can have multiple Integer IIDs. As shown in 3.3.2.7, the IID can have a length 4+n*4, where n is the number of integer interface identifiers in the parameter, or, as also shown, can have repeated parameters, each with one or more integer IIDs. The message can also have multiple Integer range IIDs or multiple text IIDs. There is no error. There is no contradiction. This is completely in fitting with the intended use of the protocol. --brian rajangam.subramanian@wipro.com wrote: (Wed, 07 Sep 2011 14:18:41) > Hello Sandeep Singh and all, > > I differ from your inference of the section 3.3.2.7 (Page 36 RFC > 3331). It would be in conflict to section 3.2 (Page 22 of RFC 3331) > which actually defines the structure of the Interface Identifier. > Section 3.3.2.7 gives an indication of the possible parameters in the > ASPAC message but does not define the structure of the parameters (Of > course there is an ambiguity in the RFC or rather error, wherein in > section 3.2 indicates M2UA specific headers are used only with MAUP > messages while they are used also with other messages like ASPSM > messages). > > > So from the structure of the Integer Interface Identifier we need to > follow section 3.2 which clearly states the length value cannot be > greater than 8. > > > Regards, > > Rajangam -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From bidulock@openss7.org Wed Sep 7 02:15:04 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 74F1121F84E5 for ; Wed, 7 Sep 2011 02:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 lYk3AxK7DyTj for ; Wed, 7 Sep 2011 02:15:04 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.117.178]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1CC21F84F9 for ; Wed, 7 Sep 2011 02:15:03 -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 p879Gd9C013798; Wed, 7 Sep 2011 03:16:39 -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 p879GcjR019627; Wed, 7 Sep 2011 03:16:38 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p879Gbp9019626; Wed, 7 Sep 2011 03:16:37 -0600 Date: Wed, 7 Sep 2011 03:16:37 -0600 From: "Brian F. G. Bidulock" To: rajangam.subramanian@wipro.com Message-ID: <20110907091637.GA17415@openss7.org> Mail-Followup-To: rajangam.subramanian@wipro.com, sandeepsinghmails@gmail.com, rajesh.makhija@aricent.com, sigtran@ietf.org, sigtran@ietfa.amsl.com, supreet_jain@yahoo.com References: <774B5A31E820C94DB1CEA7B809C399B5040389E7@CHN-SNR-MBX03.wipro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <774B5A31E820C94DB1CEA7B809C399B5040389E7@CHN-SNR-MBX03.wipro.com> 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, rajesh.makhija@aricent.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: Wed, 07 Sep 2011 09:15:04 -0000 rajangam.subramanian, Well, no. 3.2 applies to MAUP messages only. MAUP messages are specific to an interface. MAUP messages control the MTP2 signalling link and therefore must identify a specific signalling link. Therefore, the Integer IID can only identify a single signalling link for MAUP messages and the length needs to be 8. Note also that, although text IIDs are also supported, IID ranges are not. ASPTM messages, OTOH, specify a group of IIDs that belong to an AS. An AS can consist of more than one signalling link. (See 1.5.1: "An AS MAY support more than one Interface Identifier.") Therefore, the ASPAC and ASPAC Ack messages can have multiple Integer IIDs. As shown in 3.3.2.7, the IID can have a length 4+n*4, where n is the number of integer interface identifiers in the parameter, or, as also shown, can have repeated parameters, each with one or more integer IIDs. The message can also have multiple Integer range IIDs or multiple text IIDs. There is no error. There is no contradiction. This is completely in fitting with the intended use of the protocol. --brian rajangam.subramanian@wipro.com wrote: (Wed, 07 Sep 2011 14:18:41) > Hello Sandeep Singh and all, > > I differ from your inference of the section 3.3.2.7 (Page 36 RFC > 3331). It would be in conflict to section 3.2 (Page 22 of RFC 3331) > which actually defines the structure of the Interface Identifier. > Section 3.3.2.7 gives an indication of the possible parameters in the > ASPAC message but does not define the structure of the parameters (Of > course there is an ambiguity in the RFC or rather error, wherein in > section 3.2 indicates M2UA specific headers are used only with MAUP > messages while they are used also with other messages like ASPSM > messages). > > > So from the structure of the Integer Interface Identifier we need to > follow section 3.2 which clearly states the length value cannot be > greater than 8. > > > Regards, > > Rajangam -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From vishma.shetty@nsn.com Fri Sep 9 04:55:37 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 CAD2921F8A97 for ; Fri, 9 Sep 2011 04:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 MZFZK7YQ8cO4 for ; Fri, 9 Sep 2011 04:55:37 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 04DFE21F8ACA for ; Fri, 9 Sep 2011 04:55:36 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p89BvVTJ030270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 9 Sep 2011 13:57:31 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p89BvU90021239 for ; Fri, 9 Sep 2011 13:57:31 +0200 Received: from SGSIEXC007.nsn-intra.net ([10.159.224.87]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Sep 2011 13:57:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6EE7.9DFBE4AA" Date: Fri, 9 Sep 2011 19:57:14 +0800 Message-ID: <58F8E91237A10F4AA40BEBCF0A766617013130B4@SGSIEXC007.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SIGTRAN:M3UA] Query regarding the behavior of network appearance in the DAUD message Thread-Index: Acxu552nGu10NnEqSRCM8lYEVTCnpg== From: "Shetty, Vishma (NSN - IN/Bangalore)" To: X-OriginalArrivalTime: 09 Sep 2011 11:57:30.0880 (UTC) FILETIME=[A736F800:01CC6EE7] Subject: [Sigtran] [SIGTRAN:M3UA] Query regarding the behavior of network appearance in the DAUD message 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: Fri, 09 Sep 2011 11:58:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6EE7.9DFBE4AA Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCiANCg0KV2UgaGF2ZSBhIFNJR1RSQU4gc2V0dXAgd2l0aCBJVFUsIEFOU0kgYW5kIENo aW5lc2UgdmFyaWFudHMgd2l0aCBuZXR3b3JrIGFwcGVhcmFuY2UgdmFsdWVzIGNvbmZpZ3VyZWQg YXMgMSwgMiwgYW5kIDMgcmVzcGVjdGl2ZWx5IGFzIHRoZSBEVVQuDQoNCk5vdywgaWYgSSBzZW5k IGFuIElUVS1EQVVEIG1lc3NhZ2Ugd2l0aCBuZXR3b3JrIGFwcGVhcmFuY2UgdmFsdWUgYXMgMyBm cm9tIHRoZSBwZWVyIHRvIHRoZSBEVVQuIFRoZXJlIGlzIG5vIGVycm9yIG1lc3NhZ2Ugc2VudCBm cm9tIHRoZSBEVVQgdG8gdGhlIHBlZXIuIFNob3VsZCB0aGVyZSBiZSBubyBlcnJvciBtZXNzYWdl IHNlbnQgdG8gdGhlIHBlZXIgc2F5aW5nIOKAnEludmFsaWQgTmV0d29yayBBcHBlYXJhbmNl4oCd ID8gDQoNCiANCg0KQWNjb3JkaW5nIHRvIFJGQyA0NjY2LCB3ZSBzZWUgdGhhdCBJbnZhbGlkIE5l dHdvcmsgQXBwZWFyYW5jZSBlcnJvciBtZXNzYWdlIGlzIHNlbnQgZm9yIHRoZSBiZWxvdyBzY2Vu YXJpbzoNCg0KIA0KDQpUaGUgIkludmFsaWQgTmV0d29yayBBcHBlYXJhbmNlIiBlcnJvciBpcyBz ZW50IGJ5IGFuIFNHUCBpZiBhbiBBU1Agc2VuZHMgYSBtZXNzYWdlIHdpdGggYW4gaW52YWxpZCAo dW5jb25maWd1cmVkKSBOZXR3b3JrIEFwcGVhcmFuY2UgdmFsdWUuIEZvciB0aGlzIGVycm9yLCB0 aGUgaW52YWxpZCAodW5jb25maWd1cmVkKSBOZXR3b3JrIEFwcGVhcmFuY2UgTVVTVCBiZSBpbmNs dWRlZCBpbiB0aGUgTmV0d29yayBBcHBlYXJhbmNlIHBhcmFtZXRlci4NCg0KIA0KDQpTbywgZG9l cyB0aGF0IG1lYW4g4oCcaW52YWxpZCAoY29uZmlndXJlZCnigJ0gbWVhbnMgdGhlIE5BIHRoYXTi gJlzIG5vdCBjb25maWd1cmVkIGZvciBhbnkgdmFyaWFudCBvbiB0aGUgRFVUPyANCg0KIA0KDQpD b3VsZCB5b3UgcGxlYXNlIGNvbW1lbnQgb24gdGhpcyBiZWhhdmlvci4NCg0KIA0KDQogDQoNClRo YW5rcyAmIFJlZ2FyZHMsIA0KVmlzaG1hIFIgU2hldHR5IA0KDQogDQoNCg== ------_=_NextPart_001_01CC6EE7.9DFBE4AA Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RS L1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPUdlbmVyYXRvciBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxMSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+DQo8 IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpNYW5nYWw7DQoJcGFub3NlLTE6MCAwIDQgMCAwIDAgMCAwIDAgMDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEg MSAxIDEgMTt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e2NvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OkFyaWFsOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo1OTUuM3B0IDg0MS45cHQ7DQoJbWFy Z2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpT ZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGluaz1i bHVlIHZsaW5rPXB1cnBsZT4NCg0KPGRpdiBjbGFzcz1TZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZh Y2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlh bCc+V2UgaGF2ZSBhIFNJR1RSQU4gc2V0dXAgd2l0aCBJVFUsIEFOU0kgYW5kIENoaW5lc2UgdmFy aWFudHMNCndpdGggbmV0d29yayBhcHBlYXJhbmNlIHZhbHVlcyBjb25maWd1cmVkIGFzIDEsIDIs IGFuZCAzIHJlc3BlY3RpdmVseSBhcyB0aGUNCkRVVC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+Tm93LCBpZiBJIHNl bmQgYW4gSVRVLURBVUQgbWVzc2FnZSB3aXRoIG5ldHdvcmsgYXBwZWFyYW5jZQ0KdmFsdWUgYXMg MyBmcm9tIHRoZSBwZWVyIHRvIHRoZSBEVVQuIFRoZXJlIGlzIG5vIGVycm9yIG1lc3NhZ2Ugc2Vu dCBmcm9tIHRoZQ0KRFVUIHRvIHRoZSBwZWVyLiBTaG91bGQgdGhlcmUgYmUgbm8gZXJyb3IgbWVz c2FnZSBzZW50IHRvIHRoZSBwZWVyIHNheWluZyDigJxJbnZhbGlkDQpOZXR3b3JrIEFwcGVhcmFu Y2XigJ0gPyA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 DQpmb250LWZhbWlseTpBcmlhbCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPkFjY29yZGluZyB0byBSRkMg NDY2Niwgd2Ugc2VlIHRoYXQgSW52YWxpZCBOZXR3b3JrDQpBcHBlYXJhbmNlIGVycm9yIG1lc3Nh Z2UgaXMgc2VudCBmb3IgdGhlIGJlbG93IHNjZW5hcmlvOjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1sZWZ0OjcyLjBwdCc+PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMDAzMzY2Ig0KZmFjZT1Bcmlh bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjoj MDAzMzY2Jz5UaGUNCiZxdW90O0ludmFsaWQgTmV0d29yayBBcHBlYXJhbmNlJnF1b3Q7IGVycm9y IGlzIHNlbnQgYnkgYW4gU0dQIGlmIGFuIEFTUCBzZW5kcw0KYSBtZXNzYWdlIHdpdGggYW4gaW52 YWxpZCAodW5jb25maWd1cmVkKSBOZXR3b3JrIEFwcGVhcmFuY2UgdmFsdWUuIEZvciB0aGlzDQpl cnJvciwgdGhlIGludmFsaWQgKHVuY29uZmlndXJlZCkgTmV0d29yayBBcHBlYXJhbmNlIE1VU1Qg YmUgaW5jbHVkZWQgaW4gdGhlDQpOZXR3b3JrIEFwcGVhcmFuY2UgcGFyYW1ldGVyLjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWxlZnQ6NzIuMHB0Jz48Zm9udCBzaXplPTIgY29sb3I9IiMwMDMzNjYiDQpmYWNlPUFyaWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMwMDMz NjYnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MzYuMHB0Jz48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48 c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwnPlNvLCBkb2Vz IHRoYXQgbWVhbiDigJxpbnZhbGlkIChjb25maWd1cmVkKeKAnQ0KbWVhbnMgdGhlIE5BIHRoYXTi gJlzIG5vdCBjb25maWd1cmVkIGZvciBhbnkgdmFyaWFudCBvbiB0aGUgRFVUPzwvc3Bhbj48L2Zv bnQ+IDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1s ZWZ0OjM2LjBwdCc+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4NCnN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+ PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OkFyaWFsJz5Db3VsZCB5b3UgcGxlYXNlIGNvbW1lbnQgb24gdGhpcw0KYmVoYXZp b3IuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9u dC1mYW1pbHk6QXJpYWwnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBsYW5nPUVOLUdC IHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz5UaGFua3MNCiZh bXA7IFJlZ2FyZHMsPC9zcGFuPjwvZm9udD4gPGJyPg0KPGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwnPlZpc2htYQ0K UiBTaGV0dHk8L3NwYW4+PC9mb250PiA8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIGxhbmc9RU4tR0I+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjwvYm9keT4N Cg0KPC9odG1sPg0K ------_=_NextPart_001_01CC6EE7.9DFBE4AA-- From snemana@sonusnet.com Fri Sep 9 06:10:40 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 8B12E21F8B37 for ; Fri, 9 Sep 2011 06:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.661, 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 GHISebt82H6q for ; Fri, 9 Sep 2011 06:10:36 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id CBCAF21F8B31 for ; Fri, 9 Sep 2011 06:10:35 -0700 (PDT) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p89DCveQ003612; Fri, 9 Sep 2011 09:12:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6EF2.1F819728" Date: Fri, 9 Sep 2011 09:13:12 -0400 Message-ID: In-Reply-To: <58F8E91237A10F4AA40BEBCF0A766617013130B4@SGSIEXC007.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] [SIGTRAN:M3UA] Query regarding the behavior of networkappearance in the DAUD message Thread-Index: Acxu552nGu10NnEqSRCM8lYEVTCnpgACPzgA References: <58F8E91237A10F4AA40BEBCF0A766617013130B4@SGSIEXC007.nsn-intra.net> From: "Nemana, Satya" To: "Shetty, Vishma (NSN - IN/Bangalore)" , Subject: Re: [Sigtran] [SIGTRAN:M3UA] Query regarding the behavior of networkappearance in the DAUD message 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: Fri, 09 Sep 2011 13:10:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6EF2.1F819728 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Vishma =20 NA is optional in DAUD. Are there multiple ASPs on the peer AS sharing a single SCTP assoc? Is your same ASP connecting to Multiple SGP (which in turn are in multiple networks, itu, ansi and china?) If it is not connecting to multiple SGPs, then you do not need the NA at all. So, in your case the SGP is ignoring the NA parameter in the DAUD. Guess the AS is registered statically, else this problem would not have risen in case on dynamic reg. =20 What problem is this DAUD causing in the network? =20 Regards, Satya ________________________________ From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Shetty, Vishma (NSN - IN/Bangalore) Sent: 09 September 2011 12:57 To: sigtran@ietf.org Subject: [Sigtran] [SIGTRAN:M3UA] Query regarding the behavior of networkappearance in the DAUD message =20 Hi, =20 We have a SIGTRAN setup with ITU, ANSI and Chinese variants with network appearance values configured as 1, 2, and 3 respectively as the DUT. Now, if I send an ITU-DAUD message with network appearance value as 3 from the peer to the DUT. There is no error message sent from the DUT to the peer. Should there be no error message sent to the peer saying "Invalid Network Appearance" ?=20 =20 According to RFC 4666, we see that Invalid Network Appearance error message is sent for the below scenario: =20 The "Invalid Network Appearance" error is sent by an SGP if an ASP sends a message with an invalid (unconfigured) Network Appearance value. For this error, the invalid (unconfigured) Network Appearance MUST be included in the Network Appearance parameter. =20 So, does that mean "invalid (configured)" means the NA that's not configured for any variant on the DUT?=20 =20 Could you please comment on this behavior. =20 =20 Thanks & Regards,=20 Vishma R Shetty=20 =20 ------_=_NextPart_001_01CC6EF2.1F819728 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi = Vishma

 

NA is optional in = DAUD.

Are there multiple ASPs on the peer = AS sharing a single SCTP assoc?

Is your same ASP connecting to = Multiple SGP (which in turn are in multiple networks, itu, ansi and = china?)

If it is not connecting to multiple = SGPs, then you do not need the NA at all.

So, in your case the SGP is = ignoring the NA parameter in the DAUD.

Guess the AS is registered = statically, else this problem would not have risen in case on dynamic = reg.

 

What problem is this DAUD causing = in the network?

 

Regards,

Satya


From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Shetty, Vishma (NSN - = IN/Bangalore)
Sent: 09 September 2011 = 12:57
To: sigtran@ietf.org
Subject: [Sigtran] = [SIGTRAN:M3UA] Query regarding the behavior of networkappearance in the DAUD = message

 

Hi,

 

We have a SIGTRAN setup with ITU, ANSI and = Chinese variants with network appearance values configured as 1, 2, and 3 = respectively as the DUT.

Now, if I send an ITU-DAUD message with = network appearance value as 3 from the peer to the DUT. There is no error = message sent from the DUT to the peer. Should there be no error message sent to the = peer saying “Invalid Network Appearance” ? =

 

According to RFC 4666, we see that Invalid = Network Appearance error message is sent for the below = scenario:

 

The "Invalid Network Appearance" error is sent = by an SGP if an ASP sends a message with an invalid (unconfigured) Network = Appearance value. For this error, the invalid (unconfigured) Network Appearance = MUST be included in the Network Appearance = parameter.

 

So, does that = mean “invalid (configured)” means the NA that’s not = configured for any variant on the DUT? =

 

Could you = please comment on this behavior.

 

 

Thanks & Regards,
Vishma R Shetty =

 

------_=_NextPart_001_01CC6EF2.1F819728-- From vishma.shetty@nsn.com Fri Sep 9 09:13:09 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 EC89421F8B5F for ; Fri, 9 Sep 2011 09:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 J7e4VGZShZGb for ; Fri, 9 Sep 2011 09:13:09 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5795821F8B47 for ; Fri, 9 Sep 2011 09:13:08 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p89GExg1015354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Sep 2011 18:14:59 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p89GEvBT010368; Fri, 9 Sep 2011 18:14:58 +0200 Received: from SGSIEXC007.nsn-intra.net ([10.159.224.87]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Sep 2011 18:14:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6F0B.8D1E5BC7" Date: Sat, 10 Sep 2011 00:14:25 +0800 Message-ID: <58F8E91237A10F4AA40BEBCF0A76661701313167@SGSIEXC007.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] [SIGTRAN:M3UA] Query regarding the behavior of networkappearance in the DAUD message Thread-Index: Acxu552nGu10NnEqSRCM8lYEVTCnpgACPzgAAAZHTJA= References: <58F8E91237A10F4AA40BEBCF0A766617013130B4@SGSIEXC007.nsn-intra.net> From: "Shetty, Vishma (NSN - IN/Bangalore)" To: "ext Nemana, Satya" , X-OriginalArrivalTime: 09 Sep 2011 16:14:32.0275 (UTC) FILETIME=[8F151A30:01CC6F0B] Subject: Re: [Sigtran] [SIGTRAN:M3UA] Query regarding the behavior of networkappearance in the DAUD message 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: Fri, 09 Sep 2011 16:13:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6F0B.8D1E5BC7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCiANCg0KVGhhbmsgeW91IGZvciB0aGUgcmVzcG9uc2UuDQoNCiANCg0KWWVzLiBDb3Jy ZWN0LiBOQSBpcyBvcHRpb25hbC4gQnV0IHdlIHdlcmUgY2hlY2tpbmcgdGhlIGRpZmZlcmVudCBz Y2VuYXJpb3Mgd2l0aCBhbGwgdGhlIHBhcmFtZXRlcnMgaW4gdGhlIG1lc3NhZ2UuDQoNClRoZXJl IGFyZSBtdWx0aXBsZSBBU1BzIHdpdGggZGlmZmVyZW50IFNDVFAgYXNzb2NzIGZvciBhbGwgdGhl IHZhcmlhbnRzLi4gIFRoZSBzYW1lIFNHUHMgYXJlIGNvbm5lY3RlZCB0byB0aGUgQVNQcyBvZiBk aWZmZXJlbnQgdmFyaWFudHMuDQoNCkhlcmUsIHdoZW4gdGhlIG1lc3NhZ2UgZnJvbSB0aGUgQVNQ IHdpdGggdGhlIGRpZmZlcmVudCBOQSBpcyBzZW50IHRvIHRoZSBTR1AsIHdlIGNhbiBzZWUgdGhl IGVycm9yIG1lc3NhZ2UgaW4gdGhlIGxvZ3MgYXMg4oCcVW5hYmxlIHRvIGZpbmQgYW55IEFTIHNl cnZpbmcgd2l0aCBudyBhcHByIDPigJ0uIA0KDQpCdXQgSSB3YW50ZWQgdG8ga25vdyBpZiB0aGlz IGJlaGF2aW9yIGlzIGNvcnJlY3Qgb3Igc2hvdWxkIHRoZXJlIGJlIGFuIGFwcHJvcHJpYXRlIG1l c3NhZ2Ugc2VudCB0byB0aGUgQVNQIHJlZ2FyZGluZyB0aGUgc2FtZS4NCg0KIA0KDQpUaGFua3Mg JiBSZWdhcmRzLCANClZpc2htYSBSIFNoZXR0eSANCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KRnJvbTogZXh0IE5lbWFuYSwgU2F0eWEgW21haWx0bzpzbmVtYW5hQHNvbnVz bmV0LmNvbV0gDQpTZW50OiBGcmlkYXksIFNlcHRlbWJlciAwOSwgMjAxMSA2OjQzIFBNDQpUbzog U2hldHR5LCBWaXNobWEgKE5TTiAtIElOL0JhbmdhbG9yZSk7IHNpZ3RyYW5AaWV0Zi5vcmcNClN1 YmplY3Q6IFJFOiBbU2lndHJhbl0gW1NJR1RSQU46TTNVQV0gUXVlcnkgcmVnYXJkaW5nIHRoZSBi ZWhhdmlvciBvZiBuZXR3b3JrYXBwZWFyYW5jZSBpbiB0aGUgREFVRCBtZXNzYWdlDQoNCiANCg0K SGkgVmlzaG1hDQoNCiANCg0KTkEgaXMgb3B0aW9uYWwgaW4gREFVRC4NCg0KQXJlIHRoZXJlIG11 bHRpcGxlIEFTUHMgb24gdGhlIHBlZXIgQVMgc2hhcmluZyBhIHNpbmdsZSBTQ1RQIGFzc29jPw0K DQpJcyB5b3VyIHNhbWUgQVNQIGNvbm5lY3RpbmcgdG8gTXVsdGlwbGUgU0dQICh3aGljaCBpbiB0 dXJuIGFyZSBpbiBtdWx0aXBsZSBuZXR3b3JrcywgaXR1LCBhbnNpIGFuZCBjaGluYT8pDQoNCklm IGl0IGlzIG5vdCBjb25uZWN0aW5nIHRvIG11bHRpcGxlIFNHUHMsIHRoZW4geW91IGRvIG5vdCBu ZWVkIHRoZSBOQSBhdCBhbGwuDQoNClNvLCBpbiB5b3VyIGNhc2UgdGhlIFNHUCBpcyBpZ25vcmlu ZyB0aGUgTkEgcGFyYW1ldGVyIGluIHRoZSBEQVVELg0KDQpHdWVzcyB0aGUgQVMgaXMgcmVnaXN0 ZXJlZCBzdGF0aWNhbGx5LCBlbHNlIHRoaXMgcHJvYmxlbSB3b3VsZCBub3QgaGF2ZSByaXNlbiBp biBjYXNlIG9uIGR5bmFtaWMgcmVnLg0KDQogDQoNCldoYXQgcHJvYmxlbSBpcyB0aGlzIERBVUQg Y2F1c2luZyBpbiB0aGUgbmV0d29yaz8NCg0KIA0KDQpSZWdhcmRzLA0KDQpTYXR5YQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpGcm9tOiBzaWd0cmFuLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpzaWd0cmFuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTaGV0 dHksIFZpc2htYSAoTlNOIC0gSU4vQmFuZ2Fsb3JlKQ0KU2VudDogMDkgU2VwdGVtYmVyIDIwMTEg MTI6NTcNClRvOiBzaWd0cmFuQGlldGYub3JnDQpTdWJqZWN0OiBbU2lndHJhbl0gW1NJR1RSQU46 TTNVQV0gUXVlcnkgcmVnYXJkaW5nIHRoZSBiZWhhdmlvciBvZiBuZXR3b3JrYXBwZWFyYW5jZSBp biB0aGUgREFVRCBtZXNzYWdlDQoNCiANCg0KSGksDQoNCiANCg0KV2UgaGF2ZSBhIFNJR1RSQU4g c2V0dXAgd2l0aCBJVFUsIEFOU0kgYW5kIENoaW5lc2UgdmFyaWFudHMgd2l0aCBuZXR3b3JrIGFw cGVhcmFuY2UgdmFsdWVzIGNvbmZpZ3VyZWQgYXMgMSwgMiwgYW5kIDMgcmVzcGVjdGl2ZWx5IGFz IHRoZSBEVVQuDQoNCk5vdywgaWYgSSBzZW5kIGFuIElUVS1EQVVEIG1lc3NhZ2Ugd2l0aCBuZXR3 b3JrIGFwcGVhcmFuY2UgdmFsdWUgYXMgMyBmcm9tIHRoZSBwZWVyIHRvIHRoZSBEVVQuIFRoZXJl IGlzIG5vIGVycm9yIG1lc3NhZ2Ugc2VudCBmcm9tIHRoZSBEVVQgdG8gdGhlIHBlZXIuIFNob3Vs ZCB0aGVyZSBiZSBubyBlcnJvciBtZXNzYWdlIHNlbnQgdG8gdGhlIHBlZXIgc2F5aW5nIOKAnElu dmFsaWQgTmV0d29yayBBcHBlYXJhbmNl4oCdID8gDQoNCiANCg0KQWNjb3JkaW5nIHRvIFJGQyA0 NjY2LCB3ZSBzZWUgdGhhdCBJbnZhbGlkIE5ldHdvcmsgQXBwZWFyYW5jZSBlcnJvciBtZXNzYWdl IGlzIHNlbnQgZm9yIHRoZSBiZWxvdyBzY2VuYXJpbzoNCg0KIA0KDQpUaGUgIkludmFsaWQgTmV0 d29yayBBcHBlYXJhbmNlIiBlcnJvciBpcyBzZW50IGJ5IGFuIFNHUCBpZiBhbiBBU1Agc2VuZHMg YSBtZXNzYWdlIHdpdGggYW4gaW52YWxpZCAodW5jb25maWd1cmVkKSBOZXR3b3JrIEFwcGVhcmFu Y2UgdmFsdWUuIEZvciB0aGlzIGVycm9yLCB0aGUgaW52YWxpZCAodW5jb25maWd1cmVkKSBOZXR3 b3JrIEFwcGVhcmFuY2UgTVVTVCBiZSBpbmNsdWRlZCBpbiB0aGUgTmV0d29yayBBcHBlYXJhbmNl IHBhcmFtZXRlci4NCg0KIA0KDQpTbywgZG9lcyB0aGF0IG1lYW4g4oCcaW52YWxpZCAoY29uZmln dXJlZCnigJ0gbWVhbnMgdGhlIE5BIHRoYXTigJlzIG5vdCBjb25maWd1cmVkIGZvciBhbnkgdmFy aWFudCBvbiB0aGUgRFVUPyANCg0KIA0KDQpDb3VsZCB5b3UgcGxlYXNlIGNvbW1lbnQgb24gdGhp cyBiZWhhdmlvci4NCg0KIA0KDQogDQoNClRoYW5rcyAmIFJlZ2FyZHMsIA0KVmlzaG1hIFIgU2hl dHR5IA0KDQogDQoNCg== ------_=_NextPart_001_01CC6F0B.8D1E5BC7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnN0MT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNv bTpvZmZpY2U6c21hcnR0YWdzIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0 MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVudD0idGV4 dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDExIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYgIW1zb10+DQo8c3R5 bGU+DQp2XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1 cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQou c2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+DQo8IVtlbmRpZl0t LT48bzpTbWFydFRhZ1R5cGUNCiBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1j b206b2ZmaWNlOnNtYXJ0dGFncyIgbmFtZT0iUGVyc29uTmFtZSIvPg0KPCEtLVtpZiAhbXNvXT4N CjxzdHlsZT4NCnN0MVw6KntiZWhhdmlvcjp1cmwoI2RlZmF1bHQjaWVvb3VpKSB9DQo8L3N0eWxl Pg0KPCFbZW5kaWZdLS0+DQo8c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0K IEBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAx IDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpNYW5nYWw7DQoJcGFub3NlLTE6 MCAwIDQgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsN CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQogLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseTpBcmlhbDsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHls ZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OkFyaWFsOw0KCWNv bG9yOm5hdnk7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6bmF2eTt9DQpAcGFnZSBTZWN0aW9u MQ0KCXtzaXplOjU5NS4zcHQgODQxLjlwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQg OTAuMHB0O30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4N CjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCg0KPGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2 IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9y PW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFt aWx5OkFyaWFsO2NvbG9yOm5hdnknPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2 eSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz5UaGFuayB5b3UgZm9y IHRoZSByZXNwb25zZS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBz aXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4w cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+WWVzLiBDb3JyZWN0LiBOQSBpcyBvcHRp b25hbC4gQnV0IHdlIHdlcmUNCmNoZWNraW5nIHRoZSBkaWZmZXJlbnQgc2NlbmFyaW9zIHdpdGgg YWxsIHRoZSBwYXJhbWV0ZXJzIGluIHRoZSBtZXNzYWdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNl PUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7 Y29sb3I6bmF2eSc+VGhlcmUgYXJlIG11bHRpcGxlIEFTUHMgd2l0aCBkaWZmZXJlbnQNClNDVFAg YXNzb2NzIGZvciBhbGwgdGhlIHZhcmlhbnRzLi7CoCBUaGUgc2FtZSBTR1BzIGFyZSBjb25uZWN0 ZWQgdG8gdGhlIEFTUHMgb2YNCmRpZmZlcmVudCB2YXJpYW50cy48bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkg ZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFy aWFsO2NvbG9yOm5hdnknPkhlcmUsIHdoZW4gdGhlIG1lc3NhZ2UgZnJvbSB0aGUgQVNQIHdpdGgN CnRoZSBkaWZmZXJlbnQgTkEgaXMgc2VudCB0byB0aGUgU0dQLCB3ZSBjYW4gc2VlIHRoZSBlcnJv ciBtZXNzYWdlIGluIHRoZSBsb2dzDQphcyDigJxVbmFibGUgdG8gZmluZCBhbnkgQVMgc2Vydmlu ZyB3aXRoIG53IGFwcHIgM+KAnS4gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz5C dXQgSSB3YW50ZWQgdG8ga25vdyBpZiB0aGlzIGJlaGF2aW9yIGlzDQpjb3JyZWN0IG9yIHNob3Vs ZCB0aGVyZSBiZSBhbiBhcHByb3ByaWF0ZSBtZXNzYWdlIHNlbnQgdG8gdGhlIEFTUCByZWdhcmRp bmcgdGhlDQpzYW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPGRpdj4NCg0KPHA+PGZvbnQgc2l6ZT0yIGNv bG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToNCkFyaWFsO2NvbG9yOm5hdnknPlRoYW5rcyAmYW1wOyBSZWdhcmRzLDwvc3Bhbj48L2Zv bnQ+PGZvbnQgY29sb3I9bmF2eT48c3Bhbg0Kc3R5bGU9J2NvbG9yOm5hdnknPiA8YnI+DQo8L3Nw YW4+PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz5WaXNobWEg UiBTaGV0dHk8L3NwYW4+PC9mb250Pjxmb250IGNvbG9yPW5hdnk+PHNwYW4NCnN0eWxlPSdjb2xv cjpuYXZ5Jz4gPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+ DQoNCjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpj ZW50ZXInPjxmb250IHNpemU9Mw0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEyLjBwdCc+DQoNCjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRl ciB0YWJpbmRleD0tMT4NCg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxiPjxmb250IHNpemU9MiBmYWNlPVRhaG9tYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsNCmZvbnQtZmFtaWx5OlRhaG9tYTtmb250LXdlaWdodDpib2xkJz5Gcm9tOjwvc3Bhbj48 L2ZvbnQ+PC9iPjxmb250IHNpemU9Mg0KZmFjZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hJz4gZXh0IE5lbWFuYSwNClNhdHlhIFttYWlsdG86 c25lbWFuYUBzb251c25ldC5jb21dIDxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpi b2xkJz5TZW50Ojwvc3Bhbj48L2I+IEZyaWRheSwgU2VwdGVtYmVyIDA5LCAyMDExDQo2OjQzIFBN PGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlRvOjwvc3Bhbj48L2I+IDxz dDE6UGVyc29uTmFtZSB3OnN0PSJvbiI+U2hldHR5LA0KIFZpc2htYTwvc3QxOlBlcnNvbk5hbWU+ IChOU04gLSBJTi9CYW5nYWxvcmUpOyBzaWd0cmFuQGlldGYub3JnPGJyPg0KPGI+PHNwYW4gc3R5 bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlN1YmplY3Q6PC9zcGFuPjwvYj4gUkU6IFtTaWd0cmFuXQ0K W1NJR1RSQU46TTNVQV0gUXVlcnkgcmVnYXJkaW5nIHRoZSBiZWhhdmlvciBvZiBuZXR3b3JrYXBw ZWFyYW5jZSBpbiB0aGUgREFVRA0KbWVzc2FnZTwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gbGFuZz1FTi1HQg0Kc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+SGkgVmlzaG1hPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBj b2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gbGFuZz1FTi1HQg0Kc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1u YXZ5IGZhY2U9QXJpYWw+PHNwYW4gbGFuZz1FTi1HQg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+TkEgaXMgb3B0aW9uYWwgaW4gREFVRC48bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6 ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBsYW5nPUVOLUdCDQpzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz5BcmUgdGhlcmUgbXVsdGlw bGUgQVNQcw0Kb24gdGhlIHBlZXIgQVMgc2hhcmluZyBhIHNpbmdsZSBTQ1RQIGFzc29jPzxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIGxhbmc9RU4tR0INCnN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPklzIHlvdXIgc2FtZSBBU1AN CmNvbm5lY3RpbmcgdG8gTXVsdGlwbGUgU0dQICh3aGljaCBpbiB0dXJuIGFyZSBpbiBtdWx0aXBs ZSBuZXR3b3JrcywgaXR1LCBhbnNpDQphbmQgY2hpbmE/KTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNl PUFyaWFsPjxzcGFuIGxhbmc9RU4tR0INCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OkFyaWFsO2NvbG9yOm5hdnknPklmIGl0IGlzIG5vdCBjb25uZWN0aW5nDQp0byBtdWx0aXBs ZSBTR1BzLCB0aGVuIHlvdSBkbyBub3QgbmVlZCB0aGUgTkEgYXQgYWxsLjxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9 bmF2eSBmYWNlPUFyaWFsPjxzcGFuIGxhbmc9RU4tR0INCnN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPlNvLCBpbiB5b3VyIGNhc2UgdGhlIFNHUA0K aXMgaWdub3JpbmcgdGhlIE5BIHBhcmFtZXRlciBpbiB0aGUgREFVRC48bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5h dnkgZmFjZT1BcmlhbD48c3BhbiBsYW5nPUVOLUdCDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz5HdWVzcyB0aGUgQVMgaXMNCnJlZ2lzdGVyZWQg c3RhdGljYWxseSwgZWxzZSB0aGlzIHByb2JsZW0gd291bGQgbm90IGhhdmUgcmlzZW4gaW4gY2Fz ZSBvbg0KZHluYW1pYyByZWcuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gbGFu Zz1FTi1HQg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6 bmF2eSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gbGFuZz1FTi1H Qg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+ V2hhdCBwcm9ibGVtIGlzIHRoaXMgREFVRA0KY2F1c2luZyBpbiB0aGUgbmV0d29yaz88bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0y IGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBsYW5nPUVOLUdCDQpzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9y PW5hdnkgZmFjZT1BcmlhbD48c3BhbiBsYW5nPUVOLUdCDQpzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2 eSBmYWNlPUFyaWFsPjxzcGFuIGxhbmc9RU4tR0INCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPlNhdHlhPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCg0KPGRpdj4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxl PSd0ZXh0LWFsaWduOmNlbnRlcic+PGZvbnQgc2l6ZT0zDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz4NCg0KPGhyIHNpemU9MiB3aWR0aD0iMTAw JSIgYWxpZ249Y2VudGVyIHRhYmluZGV4PS0xPg0KDQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PGZvbnQgc2l6ZT0yIGZhY2U9VGFob21hPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6VGFob21hO2ZvbnQtd2VpZ2h0OmJvbGQn PkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0yDQpmYWNlPVRhaG9tYT48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWEnPg0Kc2lndHJhbi1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86c2lndHJhbi1ib3VuY2VzQGlldGYub3JnXSA8Yj48c3Bhbg0K c3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPk9uIEJlaGFsZiBPZiA8L3NwYW4+PC9iPjxzdDE6UGVy c29uTmFtZSB3OnN0PSJvbiI+U2hldHR5LA0KIFZpc2htYTwvc3QxOlBlcnNvbk5hbWU+IChOU04g LSBJTi9CYW5nYWxvcmUpPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlNl bnQ6PC9zcGFuPjwvYj4gMDkgU2VwdGVtYmVyIDIwMTEgMTI6NTc8YnI+DQo8Yj48c3BhbiBzdHls ZT0nZm9udC13ZWlnaHQ6Ym9sZCc+VG86PC9zcGFuPjwvYj4gc2lndHJhbkBpZXRmLm9yZzxicj4N CjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5TdWJqZWN0Ojwvc3Bhbj48L2I+IFtT aWd0cmFuXSBbU0lHVFJBTjpNM1VBXQ0KUXVlcnkgcmVnYXJkaW5nIHRoZSBiZWhhdmlvciBvZiBu ZXR3b3JrYXBwZWFyYW5jZSBpbiB0aGUgREFVRCBtZXNzYWdlPC9zcGFuPjwvZm9udD48bzpwPjwv bzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBsYW5nPUVOLUdCDQpzdHlsZT0nZm9udC1zaXplOjEy LjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZh Y2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlh bCc+V2UgaGF2ZSBhIFNJR1RSQU4gc2V0dXAgd2l0aCBJVFUsIEFOU0kgYW5kIENoaW5lc2UgdmFy aWFudHMNCndpdGggbmV0d29yayBhcHBlYXJhbmNlIHZhbHVlcyBjb25maWd1cmVkIGFzIDEsIDIs IGFuZCAzIHJlc3BlY3RpdmVseSBhcyB0aGUNCkRVVC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+Tm93LCBpZiBJIHNl bmQgYW4gSVRVLURBVUQgbWVzc2FnZSB3aXRoIG5ldHdvcmsgYXBwZWFyYW5jZQ0KdmFsdWUgYXMg MyBmcm9tIHRoZSBwZWVyIHRvIHRoZSBEVVQuIFRoZXJlIGlzIG5vIGVycm9yIG1lc3NhZ2Ugc2Vu dCBmcm9tIHRoZQ0KRFVUIHRvIHRoZSBwZWVyLiBTaG91bGQgdGhlcmUgYmUgbm8gZXJyb3IgbWVz c2FnZSBzZW50IHRvIHRoZSBwZWVyIHNheWluZw0K4oCcSW52YWxpZCBOZXR3b3JrIEFwcGVhcmFu Y2XigJ0gPyA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 DQpmb250LWZhbWlseTpBcmlhbCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPkFjY29yZGluZyB0byBSRkMg NDY2Niwgd2Ugc2VlIHRoYXQgSW52YWxpZCBOZXR3b3JrDQpBcHBlYXJhbmNlIGVycm9yIG1lc3Nh Z2UgaXMgc2VudCBmb3IgdGhlIGJlbG93IHNjZW5hcmlvOjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1sZWZ0OjcyLjBwdCc+PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMDAzMzY2Ig0KZmFjZT1Bcmlh bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjoj MDAzMzY2Jz5UaGUNCiZxdW90O0ludmFsaWQgTmV0d29yayBBcHBlYXJhbmNlJnF1b3Q7IGVycm9y IGlzIHNlbnQgYnkgYW4gU0dQIGlmIGFuIEFTUCBzZW5kcw0KYSBtZXNzYWdlIHdpdGggYW4gaW52 YWxpZCAodW5jb25maWd1cmVkKSBOZXR3b3JrIEFwcGVhcmFuY2UgdmFsdWUuIEZvciB0aGlzDQpl cnJvciwgdGhlIGludmFsaWQgKHVuY29uZmlndXJlZCkgTmV0d29yayBBcHBlYXJhbmNlIE1VU1Qg YmUgaW5jbHVkZWQgaW4gdGhlDQpOZXR3b3JrIEFwcGVhcmFuY2UgcGFyYW1ldGVyLjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWxlZnQ6NzIuMHB0Jz48Zm9udCBzaXplPTIgY29sb3I9IiMwMDMzNjYiDQpmYWNlPUFyaWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMwMDMz NjYnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MzYuMHB0Jz48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48 c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwnPlNvLCBkb2Vz IHRoYXQgbWVhbiDigJxpbnZhbGlkDQooY29uZmlndXJlZCnigJ0gbWVhbnMgdGhlIE5BIHRoYXTi gJlzIG5vdCBjb25maWd1cmVkIGZvciBhbnkgdmFyaWFudCBvbiB0aGUgRFVUPzwvc3Bhbj48L2Zv bnQ+DQo8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t bGVmdDozNi4wcHQnPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuDQpzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQn Pjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpBcmlhbCc+Q291bGQgeW91IHBsZWFzZSBjb21tZW50IG9uIHRoaXMNCmJlaGF2 aW9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZv bnQtZmFtaWx5OkFyaWFsJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gbGFuZz1FTi1H QiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbCc+VGhhbmtzDQom YW1wOyBSZWdhcmRzLDwvc3Bhbj48L2ZvbnQ+IDxicj4NCjxmb250IHNpemU9MiBmYWNlPUFyaWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz5WaXNobWEN ClIgU2hldHR5PC9zcGFuPjwvZm9udD4gPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBsYW5nPUVOLUdC DQpzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCg0KPC9kaXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K ------_=_NextPart_001_01CC6F0B.8D1E5BC7-- From snemana@sonusnet.com Mon Sep 26 08:41: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 BBC6211E8089 for ; Mon, 26 Sep 2011 08:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.421, 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 uQ+G5n5rnZ6G for ; Mon, 26 Sep 2011 08:41:36 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 29F3221F8D70 for ; Mon, 26 Sep 2011 08:41:35 -0700 (PDT) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p8QFimwC021024 for ; Mon, 26 Sep 2011 11:44:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC7C63.25CEBC99" Date: Mon, 26 Sep 2011 11:44:59 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCTP Multihoming Thread-index: Acx8Yz9gpywTCSz/SbSVax7ksuIBpQ== From: "Nemana, Satya" To: Subject: [Sigtran] SCTP Multihoming 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, 26 Sep 2011 15:41:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC7C63.25CEBC99 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 I have query on SCTP Multi-homing with respect to primary and secondary paths. Assuming two endpoints using multi-homing,=20 End-Point-1, EP1 has IP addresses EP1-IP1 and EP1-IP2,=20 End-Point-2, EP2 has IP addresses EP2-IP1 and EP2-IP2. Both of these interfaces are in completely different networks with different routers, etc connecting them indirectly. =20 Under this scenario would there be=20 2 paths between the two end points (EP1-IP1 <-> EP2-IP1 as path #1 and EP1-IP2 <-> EP2-IP2 as Path#2) or=20 4 paths using (EP1-IP1 <-> EP2-IP1 as path #1 and EP1-IP1 <-> EP2-IP2 as Path#2 , EP1-IP2 <-> EP2-IP1 as path#3 and EP1-IP2 <-> EP2-IP2) =20 If there are 4 paths, how would IP routing take care of such a scenario, i.e how would the route tables look like on EP1? How can EP1 have 2 routes to the same EP2-IP1 IP address through 2 different local interfaces on EP1? =20 TIA, =20 Regards, Satya ------_=_NextPart_001_01CC7C63.25CEBC99 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

I have query on SCTP Multi-homing with respect to = primary and secondary paths.

Assuming two endpoints using multi-homing, =

End-Point-1, EP1 has IP = addresses EP1-IP1 and EP1-IP2,

End-Point-2, EP2 has IP = addresses EP2-IP1 and EP2-IP2.

Both of these interfaces are in completely different networks with different routers, etc connecting them = indirectly.

 

Under this scenario would there be =

2 paths between the two end points (EP1-IP1 <-> = EP2-IP1 as path #1 and EP1-IP2 <-> EP2-IP2 as Path#2) or =

4 paths using (EP1-IP1 <-> EP2-IP1 as path #1 = and EP1-IP1 <-> EP2-IP2 as Path#2 , EP1-IP2 <-> EP2-IP1 as = path#3 and EP1-IP2 <-> EP2-IP2)

 

If there are 4 paths, how would IP routing take care = of such a scenario, i.e how would the route tables look like on = EP1?

How can EP1 have 2 routes to the same EP2-IP1 IP = address through 2 different local interfaces on EP1?

 

TIA,

 

Regards,

Satya

------_=_NextPart_001_01CC7C63.25CEBC99-- From cbenson@adax.com Mon Sep 26 09:52:37 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 EF90021F8C70 for ; Mon, 26 Sep 2011 09:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 1AdeBWJzc-Xp for ; Mon, 26 Sep 2011 09:52:36 -0700 (PDT) Received: from mail1.adax.com (mail1.adax.com [70.36.226.176]) by ietfa.amsl.com (Postfix) with ESMTP id 46D6821F8C6C for ; Mon, 26 Sep 2011 09:52:36 -0700 (PDT) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id 19D6D1E13EF; Mon, 26 Sep 2011 09:55:19 -0700 (PDT) Received: by adax (Postfix, from userid 243) id 71A538EE11; Mon, 26 Sep 2011 09:57:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id 67FF38EE10; Mon, 26 Sep 2011 09:57:21 -0700 (PDT) Date: Mon, 26 Sep 2011 09:57:21 -0700 (PDT) From: Chris Benson X-X-Sender: cbenson@adax.adax To: "Nemana, Satya" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: sigtran@ietf.org Subject: Re: [Sigtran] SCTP Multihoming 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, 26 Sep 2011 16:52:37 -0000 Satya, There are four combinations of end-point pairs. Two of them may or may not be "usable". It is desirable (but not always possible) for an IP layer to comply with IP-user specification of the local outgoing originating source IP address. SCTP is the IP-user, and so can/should/will specify the originating local source IP address. This restricts IP's local selection of outgoing interface, and any routing decisions are made from within that restricted context. Each single interface may be on physically distinct hardware, or they may be shared through one physical egress. Either way, the concept is the same. FOUR USABLE: ============ If the inter-network cloud is such that all source IP addresses can eventually/somehow reach all destination IP addresses, such as in the Internet context, then there are four usable paths. TWO USABLE, TWO NOT: ==================== It is possible to construct two distinct isolated "private" IP networks: one for your IP1 addresses, and a separate unconected one for your IP2 addresses. There would only be two USABLE paths, but under certain circumstances SCTP might TRY all four end-point combinations, and will discover the lack of connectivity. With thanks, from Chris Benson. On Mon, 26 Sep 2011, Nemana, Satya wrote: >> Date: Mon, 26 Sep 2011 11:44:59 -0400 >> From: "Nemana, Satya" >> To: >> Subject: [Sigtran] SCTP Multihoming >> >> Hi >> >> >> >> I have query on SCTP Multi-homing with respect to primary and secondary >> paths. >> >> Assuming two endpoints using multi-homing, >> >> End-Point-1, EP1 has IP addresses EP1-IP1 and EP1-IP2, >> >> End-Point-2, EP2 has IP addresses EP2-IP1 and EP2-IP2. >> >> Both of these interfaces are in completely different networks with >> different routers, etc connecting them indirectly. >> >> >> >> Under this scenario would there be >> >> 2 paths between the two end points (EP1-IP1 <-> EP2-IP1 as path #1 and >> EP1-IP2 <-> EP2-IP2 as Path#2) or >> >> 4 paths using (EP1-IP1 <-> EP2-IP1 as path #1 and EP1-IP1 <-> EP2-IP2 as >> Path#2 , EP1-IP2 <-> EP2-IP1 as path#3 and EP1-IP2 <-> EP2-IP2) >> >> >> >> If there are 4 paths, how would IP routing take care of such a scenario, >> i.e how would the route tables look like on EP1? >> >> How can EP1 have 2 routes to the same EP2-IP1 IP address through 2 >> different local interfaces on EP1? >> >> >> >> TIA, >> >> >> >> Regards, >> >> Satya >> >>