June 2001 - sg16-avd - lists.packetizer.com

Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL
by Callaghan, Robert 01 Jun '01

01 Jun '01

Gary, In the direct call routed model, Gatekeepers only register and authorize endpoints can calls. The call control messages do not involve the gatekeepers and therefore cannot control the gatekeeper handling of the call. Even in a gatekeeper routed model, there is no need for more than two gatekeepers (originating and terminating). There can be a lot of space and networks between the two. Firewalls tend to be used to isolate an enterprise network from a public network. The public network involves many providers and network segments without any firewalls. The application layer signaling data stream may be able to control its QOS. In that the RTP streaming data transport is separately routed from the application data stream. And it is not possible for one stream to control another stream without a fundamental change to the Internet fabric. I doubt that this will happen. If it does happen, it will not be fully implements for a very long time. (One of the IETF people proposed that this is not an engineering problem but the basis for a research project.) Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan(a)ICN.Siemens.com ----------------------------------------------------------------- -----Original Message----- From: Gary Thom [mailto:gthom@delta-info.com] Sent: Friday, June 01, 2001 10:24 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL The application layer QOS should be an indication of the abstract quality and priority requirements or capabilities. This should really be called "Application Level Service Class" because it affects more than just the transpost level QOS mechanisms. It also affects Gatekeeper and Gateway behaviour. This should be independent of the transport layer mechanisms. The mapping of service class to transport level QOS and Gatekeeper and Gateway behavior is an implementation issue or is subject to service level agreements. Gary -------------------------------------------- Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 x123 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com Website: www.delta-info.com -------------------------------------------- -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@MAILBAG.INTEL.COM]On Behalf Of Roy, Radhika R, ALCTA Sent: Friday, June 01, 2001 9:44 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Hi, Bob: You are right that the application layer does not control the lower layers (e.g., RTP, UDP, IP). So, there is a requirement how the lower layers can be coupled for implementation in cooperation with the higher layer. The fact of the matter is that the lower layers are responsible for sending the media streams between the source and destination path. This is the area for implementations and we have to see how far the SG16 is going to dig to address this problem because our works will be limited mostly in the upper application layer. AT&T contributions in the SG16 Brazil (May-June'01) meeting provide a framework how to address this problem. Any contributions along this line will be highly appreciated. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Friday, June 01, 2001 9:24 AM To: Roy, Radhika R, ALCTA; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Please note that the network layer QOS (e.g., RSVP, DiffServe, and/or MPLS) may or may not have the end-to-end significance. For example, an IP network may implement different QOS schemes in different domains (e.g., RVSP in one domain, DiffServ in another domain). However, the application layer QOS is end-to-end that remains the same. For example, an H.323 or SIP call that can traverse several IP domains where each domain may implement its own network layer QOS schemes while the H.323/SIP call carry the signaling messages and QOS parameters end-to-end independent of the underlying network layer QOS mechanisms. Yes, the application layer is end-to-end. But does it traverse the exact same route as RTP transport layer? I don't think so, in that this is not IP. IP routes each packet individually with the right to change routes independently for each stream, and each packet in a stream. This is the basis for load balancing, overload control, and link failure survivability. With this in mind, the application layer can negotiate an end-to-end QOS with the ends. It cannot control the intermediate routing nodes. A method is needed to accomplish the end-to-end QOS control via the RTP IP stream. Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan(a)ICN.Siemens.com ----------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL
by Roy, Radhika R, ALCTA 01 Jun '01

01 Jun '01

Hi, Gary: Yes, this is the idea as you have indicated. With respect to service classes let me add as follows: The service classes are nothing but composed of some attributes that have the implications for a group of performance parameters. 1. Dynamic and Pre-defined Service Classes Grouping Performance Parameters with no "values" of any Parameters So, endusers will be able to signal any group of performance parameters (that may imply a given service class) as they wish and the negotiation capability will be provided to choose the common set of performance parameters as they like to accept. This is called the creation of service classes dynamically. (For example, class 1 = (delay, jitter, losses), class 2 = (delay, jitter), class 3 = (delay), etc.) If needed, the flexibility can also be provided for a pre-defined service classes as well. 2. Dynamic and Pre-defined Service Classes Grouping Performance Parameters with specific "values" of all Parameters In addition to item 1, the service classes can be further be created dynamically or pre-defined assigning some specific value for each parameter and then group them together. (For example, delay = 50 mSecs (Class 3/Gold), delay = 100 (class 3 - silver), delay = 150 mSecs (class 3 - bronze), etc.) We can keep so many flexibilities in defining service classes. Best regards, Radhika -----Original Message----- From: Gary Thom [mailto:gthom@delta-info.com] Sent: Friday, June 01, 2001 10:24 AM To: Roy, Radhika R, ALCTA; ITU-SG16(a)MAILBAG.INTEL.COM Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL The application layer QOS should be an indication of the abstract quality and priority requirements or capabilities. This should really be called "Application Level Service Class" because it affects more than just the transpost level QOS mechanisms. It also affects Gatekeeper and Gateway behaviour. This should be independent of the transport layer mechanisms. The mapping of service class to transport level QOS and Gatekeeper and Gateway behavior is an implementation issue or is subject to service level agreements. Gary -------------------------------------------- Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 x123 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com Website: www.delta-info.com -------------------------------------------- -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@MAILBAG.INTEL.COM]On Behalf Of Roy, Radhika R, ALCTA Sent: Friday, June 01, 2001 9:44 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Hi, Bob: You are right that the application layer does not control the lower layers (e.g., RTP, UDP, IP). So, there is a requirement how the lower layers can be coupled for implementation in cooperation with the higher layer. The fact of the matter is that the lower layers are responsible for sending the media streams between the source and destination path. This is the area for implementations and we have to see how far the SG16 is going to dig to address this problem because our works will be limited mostly in the upper application layer. AT&T contributions in the SG16 Brazil (May-June'01) meeting provide a framework how to address this problem. Any contributions along this line will be highly appreciated. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Friday, June 01, 2001 9:24 AM To: Roy, Radhika R, ALCTA; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Please note that the network layer QOS (e.g., RSVP, DiffServe, and/or MPLS) may or may not have the end-to-end significance. For example, an IP network may implement different QOS schemes in different domains (e.g., RVSP in one domain, DiffServ in another domain). However, the application layer QOS is end-to-end that remains the same. For example, an H.323 or SIP call that can traverse several IP domains where each domain may implement its own network layer QOS schemes while the H.323/SIP call carry the signaling messages and QOS parameters end-to-end independent of the underlying network layer QOS mechanisms. Yes, the application layer is end-to-end. But does it traverse the exact same route as RTP transport layer? I don't think so, in that this is not IP. IP routes each packet individually with the right to change routes independently for each stream, and each packet in a stream. This is the basis for load balancing, overload control, and link failure survivability. With this in mind, the application layer can negotiate an end-to-end QOS with the ends. It cannot control the intermediate routing nodes. A method is needed to accomplish the end-to-end QOS control via the RTP IP stream. Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan(a)ICN.Siemens.com ----------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL
by Roy, Radhika R, ALCTA 01 Jun '01

01 Jun '01

Hi, Bob and Gary: Bob is right that there are many problems: Firewalls, NATs, RTP signaling to UDP to IP, etc. However, RSVP, DiffServ, and MPLS schemes are there that are being used in the network layer. So, the application layer is not supposed to do anything NEW other than to establish a relationship between the existing network layer QOS so that the consistency remains on end-to-end basis. (Bob is right that the problems of addressing the public Internet QOS are not so easy - may be "best-effort" is the easy way to do something!!) Best regards, Radhika -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Friday, June 01, 2001 10:57 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Gary, In the direct call routed model, Gatekeepers only register and authorize endpoints can calls. The call control messages do not involve the gatekeepers and therefore cannot control the gatekeeper handling of the call. Even in a gatekeeper routed model, there is no need for more than two gatekeepers (originating and terminating). There can be a lot of space and networks between the two. Firewalls tend to be used to isolate an enterprise network from a public network. The public network involves many providers and network segments without any firewalls. The application layer signaling data stream may be able to control its QOS. In that the RTP streaming data transport is separately routed from the application data stream. And it is not possible for one stream to control another stream without a fundamental change to the Internet fabric. I doubt that this will happen. If it does happen, it will not be fully implements for a very long time. (One of the IETF people proposed that this is not an engineering problem but the basis for a research project.) Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan(a)ICN.Siemens.com ----------------------------------------------------------------- -----Original Message----- From: Gary Thom [mailto:gthom@delta-info.com] Sent: Friday, June 01, 2001 10:24 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL The application layer QOS should be an indication of the abstract quality and priority requirements or capabilities. This should really be called "Application Level Service Class" because it affects more than just the transpost level QOS mechanisms. It also affects Gatekeeper and Gateway behaviour. This should be independent of the transport layer mechanisms. The mapping of service class to transport level QOS and Gatekeeper and Gateway behavior is an implementation issue or is subject to service level agreements. Gary -------------------------------------------- Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 x123 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com Website: www.delta-info.com -------------------------------------------- -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@MAILBAG.INTEL.COM]On Behalf Of Roy, Radhika R, ALCTA Sent: Friday, June 01, 2001 9:44 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Hi, Bob: You are right that the application layer does not control the lower layers (e.g., RTP, UDP, IP). So, there is a requirement how the lower layers can be coupled for implementation in cooperation with the higher layer. The fact of the matter is that the lower layers are responsible for sending the media streams between the source and destination path. This is the area for implementations and we have to see how far the SG16 is going to dig to address this problem because our works will be limited mostly in the upper application layer. AT&T contributions in the SG16 Brazil (May-June'01) meeting provide a framework how to address this problem. Any contributions along this line will be highly appreciated. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Friday, June 01, 2001 9:24 AM To: Roy, Radhika R, ALCTA; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Please note that the network layer QOS (e.g., RSVP, DiffServe, and/or MPLS) may or may not have the end-to-end significance. For example, an IP network may implement different QOS schemes in different domains (e.g., RVSP in one domain, DiffServ in another domain). However, the application layer QOS is end-to-end that remains the same. For example, an H.323 or SIP call that can traverse several IP domains where each domain may implement its own network layer QOS schemes while the H.323/SIP call carry the signaling messages and QOS parameters end-to-end independent of the underlying network layer QOS mechanisms. Yes, the application layer is end-to-end. But does it traverse the exact same route as RTP transport layer? I don't think so, in that this is not IP. IP routes each packet individually with the right to change routes independently for each stream, and each packet in a stream. This is the basis for load balancing, overload control, and link failure survivability. With this in mind, the application layer can negotiate an end-to-end QOS with the ends. It cannot control the intermediate routing nodes. A method is needed to accomplish the end-to-end QOS control via the RTP IP stream. Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan(a)ICN.Siemens.com ----------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL
by Roy, Radhika R, ALCTA 01 Jun '01

01 Jun '01

Hi, Bob: You are right that the application layer does not control the lower layers (e.g., RTP, UDP, IP). So, there is a requirement how the lower layers can be coupled for implementation in cooperation with the higher layer. The fact of the matter is that the lower layers are responsible for sending the media streams between the source and destination path. This is the area for implementations and we have to see how far the SG16 is going to dig to address this problem because our works will be limited mostly in the upper application layer. AT&T contributions in the SG16 Brazil (May-June'01) meeting provide a framework how to address this problem. Any contributions along this line will be highly appreciated. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Friday, June 01, 2001 9:24 AM To: Roy, Radhika R, ALCTA; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Please note that the network layer QOS (e.g., RSVP, DiffServe, and/or MPLS) may or may not have the end-to-end significance. For example, an IP network may implement different QOS schemes in different domains (e.g., RVSP in one domain, DiffServ in another domain). However, the application layer QOS is end-to-end that remains the same. For example, an H.323 or SIP call that can traverse several IP domains where each domain may implement its own network layer QOS schemes while the H.323/SIP call carry the signaling messages and QOS parameters end-to-end independent of the underlying network layer QOS mechanisms. Yes, the application layer is end-to-end. But does it traverse the exact same route as RTP transport layer? I don't think so, in that this is not IP. IP routes each packet individually with the right to change routes independently for each stream, and each packet in a stream. This is the basis for load balancing, overload control, and link failure survivability. With this in mind, the application layer can negotiate an end-to-end QOS with the ends. It cannot control the intermediate routing nodes. A method is needed to accomplish the end-to-end QOS control via the RTP IP stream. Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan(a)ICN.Siemens.com ----------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL
by Callaghan, Robert 01 Jun '01

01 Jun '01

Please note that the network layer QOS (e.g., RSVP, DiffServe, and/or MPLS) may or may not have the end-to-end significance. For example, an IP network may implement different QOS schemes in different domains (e.g., RVSP in one domain, DiffServ in another domain). However, the application layer QOS is end-to-end that remains the same. For example, an H.323 or SIP call that can traverse several IP domains where each domain may implement its own network layer QOS schemes while the H.323/SIP call carry the signaling messages and QOS parameters end-to-end independent of the underlying network layer QOS mechanisms. Yes, the application layer is end-to-end. But does it traverse the exact same route as RTP transport layer? I don't think so, in that this is not IP. IP routes each packet individually with the right to change routes independently for each stream, and each packet in a stream. This is the basis for load balancing, overload control, and link failure survivability. With this in mind, the application layer can negotiate an end-to-end QOS with the ends. It cannot control the intermediate routing nodes. A method is needed to accomplish the end-to-end QOS control via the RTP IP stream. Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan(a)ICN.Siemens.com ----------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW:
by Euchner Martin 01 Jun '01

01 Jun '01

I think that's correctly stated. Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 5 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/network_technology/security/pki.htm | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: ssilvy(a)HSS.HNS.COM [SMTP:ssilvy@HSS.HNS.COM] Gesendet am: Freitag, 1. Juni 2001 06:26 An: ITU-SG16(a)mailbag.cps.INTEL.COM Betreff: Hi, In case of initial RRQ when EPID is not available the table D.10 in H235v2 says that sendersID would be NULL. So the hash would be calculated with sendersID as NULL when the identification information i.e EPID is not available as in initial RRQ. Silvy. Nagesh Kumar B V 06/01/2001 10:40 AM To: Silvy Samuel/HSSBLR@HSSBLR, Ivan T Varghis/HSSBLR@HSSBLR cc: Subject: ---------------------- Forwarded by Nagesh Kumar B V/HSSBLR on 06/01/2001 09:46 AM --------------------------- "Paul, Manoj" <mpaul(a)TRILLIUM.COM> on 05/31/2001 06:35:31 PM Please respond to "Paul, Manoj" <mpaul(a)TRILLIUM.COM> To: ITU-SG16(a)mailbag.cps.INTEL.COM cc: (bcc: Nagesh Kumar B V/HSSBLR) Subject: Hi All, I have a question on the use of H.235 Annex D (Baseline Security Profile). According to this profile, except for GRQ/GCF messages, all other RAS messages shall contain a hash value computed using HMAC-SHA1-96 algorightm on the entire RAS message. Consider an endpoint sending RRQ to the Gk. In the clearToken field of RRQ message, the endpoint shall fill generalId as gkId (which it got in GCF) and senderId as it's own epId. EpId is generally returned to the endpoint by the gatekeeper in RCF. That means that an endpoint may not have an epId while sending RRQ to Gk. In such a case, how it is supposed to fill the senderId and compute the hash value on complete RRQ message? Any pointers are appreciated. thanks Manoj Paul. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

None
by ssilvy＠HSS.HNS.COM 01 Jun '01

01 Jun '01

Hi, In case of initial RRQ when EPID is not available the table D.10 in H235v2 says that sendersID would be NULL. So the hash would be calculated with sendersID as NULL when the identification information i.e EPID is not available as in initial RRQ. Silvy. Nagesh Kumar B V 06/01/2001 10:40 AM To: Silvy Samuel/HSSBLR@HSSBLR, Ivan T Varghis/HSSBLR@HSSBLR cc: Subject: ---------------------- Forwarded by Nagesh Kumar B V/HSSBLR on 06/01/2001 09:46 AM --------------------------- "Paul, Manoj" <mpaul(a)TRILLIUM.COM> on 05/31/2001 06:35:31 PM Please respond to "Paul, Manoj" <mpaul(a)TRILLIUM.COM> To: ITU-SG16(a)mailbag.cps.INTEL.COM cc: (bcc: Nagesh Kumar B V/HSSBLR) Subject: Hi All, I have a question on the use of H.235 Annex D (Baseline Security Profile). According to this profile, except for GRQ/GCF messages, all other RAS messages shall contain a hash value computed using HMAC-SHA1-96 algorightm on the entire RAS message. Consider an endpoint sending RRQ to the Gk. In the clearToken field of RRQ message, the endpoint shall fill generalId as gkId (which it got in GCF) and senderId as it's own epId. EpId is generally returned to the endpoint by the gatekeeper in RCF. That means that an endpoint may not have an epId while sending RRQ to Gk. In such a case, how it is supposed to fill the senderId and compute the hash value on complete RRQ message? Any pointers are appreciated. thanks Manoj Paul. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0