From shida@ntt-at.com Wed Jun 1 17:04:48 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9E9E085A for ; Wed, 1 Jun 2011 17:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlymdbWSu7EL for ; Wed, 1 Jun 2011 17:04:46 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 525F5E06EB for ; Wed, 1 Jun 2011 17:04:44 -0700 (PDT) Received: from [220.102.208.30] (port=49585 helo=[192.168.1.3]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QRvOw-0006XN-Pg; Wed, 01 Jun 2011 19:04:39 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <201105302334.p4UNYgSj010236@mtv-core-2.cisco.com> Date: Thu, 2 Jun 2011 09:04:38 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <1D7207A8-5FAE-4D59-8F6E-1855B10C3BB8@ntt-at.com> References: <30E0133A-9869-41B1-BCB2-B32E369D7ABB@cs.columbia.edu> <201105302334.p4UNYgSj010236@mtv-core-2.cisco.com> To: James M. Polk X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: flh1acy030.tky.mesh.ad.jp ([192.168.1.3]) [220.102.208.30]:49585 X-Source-Auth: shida@agnada.com X-Email-Count: 0 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: dispatch@ietf.org, Jong Yul Kim Subject: Re: [dispatch] Emergency Text Messaging using SIP MESSAGE X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 00:04:48 -0000 I agree with James here. It should be run by ECRIT WG. Also, although I haven't gone through this draft, ECRIT=20 already has a draft discussing the use of MESSAGE method=20 in the context of emergency call.=20 http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-01 Regards Shida On May 31, 2011, at 8:34 AM, James M. Polk wrote: > At 07:54 AM 5/30/2011, Jong Yul Kim wrote: >> Hi everyone, >>=20 >> This draft presents mechanisms to allow page-mode text messaging in = emergency situations. >=20 > Doesn't this whole idea of including text that talks about emergency = services need to get run by the ECRIT WG before the topic can be = included anywhere? >=20 > James >=20 >=20 >> An example of page-mode messaging is when a person sends SMS to an = emergency number to get help. In this case, there needs to be a way for = the SMS message to reach the same call taker until the "conversation" = ends. >>=20 >> As emergency call centers are transitioning to a SIP-based solution, = the draft outlines a mechanism based on SIP MESSAGE method to deliver = page-mode messages consistently to a call taker. >>=20 >> http://tools.ietf.org/html/draft-kim-dispatch-text-01 >>=20 >> Comments on the draft or which WG it should go to are much = appreciated. >> Please let us know your thoughts. >>=20 >> Best regards, >>=20 >> Jong Yul >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From jyk@cs.columbia.edu Wed Jun 1 20:22:47 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5BCE084D for ; Wed, 1 Jun 2011 20:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.534 X-Spam-Level: X-Spam-Status: No, score=-4.534 tagged_above=-999 required=5 tests=[AWL=-1.935, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPVY2dmdAbYH for ; Wed, 1 Jun 2011 20:22:47 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 82481E06E9 for ; Wed, 1 Jun 2011 20:22:44 -0700 (PDT) Received: from [192.168.1.109] (user-12lc543.cable.mindspring.com [69.86.20.131]) (user=jk2520 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p523MeJu021119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 1 Jun 2011 23:22:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jong Yul Kim In-Reply-To: <1D7207A8-5FAE-4D59-8F6E-1855B10C3BB8@ntt-at.com> Date: Wed, 1 Jun 2011 23:22:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <134712A1-7344-4F8C-8A2F-8E9A3D84E786@cs.columbia.edu> References: <30E0133A-9869-41B1-BCB2-B32E369D7ABB@cs.columbia.edu> <201105302334.p4UNYgSj010236@mtv-core-2.cisco.com> <1D7207A8-5FAE-4D59-8F6E-1855B10C3BB8@ntt-at.com> To: Shida Schubert X-Mailer: Apple Mail (2.1084) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: dispatch@ietf.org Subject: Re: [dispatch] Emergency Text Messaging using SIP MESSAGE X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 03:22:47 -0000 Thank you, everyone, for your valuable comments.=20 The draft has been 'floating' around the ECRIT WG until it was suggested = that we submit it to this WG to see where it would fit.=20 I wasn't aware of another ECRIT draft about the MESSAGE method.=20 I will check it out and perhaps move the discussion to ECRIT if it's = appropriate.=20 Dale: thank you for your comments on the draft. I will get back to you = soon.=20 Regards,=20 Jong Yul=20 On Jun 1, 2011, at 8:04 PM, Shida Schubert wrote: >=20 > I agree with James here. It should be run by ECRIT WG. >=20 > Also, although I haven't gone through this draft, ECRIT=20 > already has a draft discussing the use of MESSAGE method=20 > in the context of emergency call.=20 >=20 > http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-01 >=20 > Regards > Shida >=20 > On May 31, 2011, at 8:34 AM, James M. Polk wrote: >=20 >> At 07:54 AM 5/30/2011, Jong Yul Kim wrote: >>> Hi everyone, >>>=20 >>> This draft presents mechanisms to allow page-mode text messaging in = emergency situations. >>=20 >> Doesn't this whole idea of including text that talks about emergency = services need to get run by the ECRIT WG before the topic can be = included anywhere? >>=20 >> James >>=20 >>=20 >>> An example of page-mode messaging is when a person sends SMS to an = emergency number to get help. In this case, there needs to be a way for = the SMS message to reach the same call taker until the "conversation" = ends. >>>=20 >>> As emergency call centers are transitioning to a SIP-based solution, = the draft outlines a mechanism based on SIP MESSAGE method to deliver = page-mode messages consistently to a call taker. >>>=20 >>> http://tools.ietf.org/html/draft-kim-dispatch-text-01 >>>=20 >>> Comments on the draft or which WG it should go to are much = appreciated. >>> Please let us know your thoughts. >>>=20 >>> Best regards, >>>=20 >>> Jong Yul >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 >=20 From spromano@unina.it Fri Jun 3 11:35:19 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89B1E07A9 for ; Fri, 3 Jun 2011 11:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.408 X-Spam-Level: X-Spam-Status: No, score=-100.408 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6RVDsfzATWd for ; Fri, 3 Jun 2011 11:35:18 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 60667E079A for ; Fri, 3 Jun 2011 11:35:16 -0700 (PDT) Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id p53IZBIU031163 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 3 Jun 2011 20:35:13 +0200 Message-ID: <4DE92958.8080907@unina.it> Date: Fri, 03 Jun 2011 20:35:04 +0200 From: Simon Pietro Romano User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Salvatore Loreto References: <4DDA0388.60702@ericsson.com> In-Reply-To: <4DDA0388.60702@ericsson.com> Content-Type: multipart/alternative; boundary="------------070106080006030904070403" Cc: "dispatch@ietf.org" Subject: Re: [dispatch] charter proposal: SIP end-to-end Session Identifier X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 18:35:20 -0000 This is a multi-part message in MIME format. --------------070106080006030904070403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit This idea has been around for a while. I find it both interesting and worth discussing in a narrow-scoped WG like the one you are proposing. Simon Il 23/05/2011 08:49, Salvatore Loreto ha scritto: > > Hi there, > > below a charter proposal for a new wg working on End-to-end Session > Identifier in SIP. > > > In an effort to make progress and to facilitate the discussion > we have also created an Internet Draft that captures, at a high level, > the requirements and use cases. > (It was submitted by Paul E. Jones last Friday; here the link: > http://www.ietf.org/id/draft-jones-ipmc-session-id-reqts-00.txt ) > > > cheers > /Sal > > End-to-end Session Identifier in SIP (charter proposal ) > ---------------------------------------------- > > > The end-to-end Session Identifier in an SIP-based multimedia > communication refers to the ability > for endpoints, intermediate devices, and management and monitoring > system to identify > and correlate SIP messages and dialogs of the same higher-level > end-to-end "communication > session" across multiple SIP devices and hops. > > Unfortunately, there are a number of factors that contribute to the > fact that the current > dialog identifiers as defined in SIP is not suitable for end-to-end > session identification. > Perhaps the most important factor worth describing is that in real-world > deployments devices like Session Border Controllers (SBC) often change > the current call > identifiers (e.g., the From-tag and To-tag that are used in > conjunction with the Call-ID header > to make the dialog-id) as the session signaling passes through. > > > > An end-to-end Session Identifier should allow the possibility to > identify the communication session > from the point of origin, passing through any number of > intermediaries, to the ultimate point > of termination. It should have the same aim as the From-tag, To-tag > and Call-ID conjunction, > but should not be mangled by intermediaries. > > > A SIP end-to-end Session Identifier has been consideredas possible > solution of different use cases like > troubleshooting, billing, session tracking, session recording, media > and signaling correlation, and so forth. > Some of these requirements have also been identified and come directly > from other existing > working group within the RAI area (e.g. SIPRec, Splices). > > > Moreover, otherSDOs have identified the need for SIP and H.323 to > carry the same "session ID" value(s) > so that it is possible identify a call end-to end even when performing > inter working between > protocols. > > > This group will first focus on adocument that will identify, collect > and discuss all the > requirements and the use cases that have been identified. > The document may identify the possibility to design a general > mechanism or the need > to design multiple purpose built identifiers. > Once the needs are clear and identified, the working group will > specify the mechanism(s). > > > Specifically, the proposed working group will develop the following > deliverable: > > 1. A requirement and use case document with key consideration for > SIP Session > End-to-End identifier. The document will discuss the possibility > of designing > a general mechanism or the needs to design multiple purpose > build identifier. > 2. Specification of new mechanism(s). > > > Goal and Milestone: > October 2011 - Requirement and use case document sent to the IESG > (Information) > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ --------------070106080006030904070403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This idea has been around for a while. I find it both interesting and worth discussing in a narrow-scoped WG like the one you are proposing.

Simon

Il 23/05/2011 08:49, Salvatore Loreto ha scritto:

Hi there,

below a charter proposal for a new wg working on End-to-end Session Identifier in SIP.


In an effort to make progress and to facilitate the discussion
we have also created an Internet Draft that captures, at a high level,
the requirements and use cases.
(It was submitted by Paul E. Jones last Friday; here the link:
http://www.ietf.org/id/draft-jones-ipmc-session-id-reqts-00.txt )


cheers
/Sal


      
End-to-end Session Identifier
          in SIP (charter proposal )

          ----------------------------------------------

        

      


          The end-to-end Session Identifier in an SIP-based multimedia
          communication refers to the ability

          for endpoints, intermediate devices, and management and
          monitoring system to identify

          and correlate SIP messages and dialogs of the same
          higher-level end-to-end "communication 

          session" across multiple SIP devices and hops. 

          

          Unfortunately, there are a number of factors that contribute
          to the fact that the current

          dialog identifiers as defined in SIP is not suitable for
          end-to-end session identification.

          Perhaps the most important factor worth describing is that in
          real-world 

          deployments devices like Session Border Controllers (SBC)
          often change the current call 

          identifiers (e.g., the From-tag and To-tag that are used in
          conjunction with the Call-ID header

          to make the dialog-id) as the session signaling passes
          through.

      


          

          An end-to-end Session Identifier should allow the possibility
          to identify the communication session

          from the point of origin, passing through any number of
          intermediaries, to the ultimate point

          of termination. It should have the same aim as the From-tag,
          To-tag and Call-ID conjunction,

          but should not be mangled by intermediaries. 

      


        A SIP end-to-end Session Identifier has been considered as possible solution
        of different use cases like 

        troubleshooting, billing, session tracking, session recording,
        media and signaling correlation, and so forth.

        Some of these requirements have also been identified and come
        directly from other existing 

        working group within the RAI area (e.g. SIPRec, Splices).

      


        Moreover, other SDOs

        have identified the need for SIP and H.323 to carry the same
        "session ID" value(s)

        so that it is possible identify a call end-to end even when
        performing inter working between

        protocols.

        

        

        This group will first focus on a document that will identify, collect and
        discuss all the 

        requirements and the use cases that have been identified.

        The document may identify the possibility to design a general
        mechanism or the need

        to design multiple purpose built identifiers. 

        Once the needs are clear and identified, the working group will
        specify the mechanism(s).

        

        

        Specifically, the proposed working group will develop the
        following deliverable:

      
    
        
  1. A requirement and
            use case document with key consideration for SIP Session
    
            End-to-End identifier. The document will discuss the
            possibility of designing
    
            a general mechanism or the needs to design multiple purpose
            build identifier.
    2. 
        
  2. Specification of
            new mechanism(s).
    3. 
      

      


        Goal and Milestone:

            October 2011 - Requirement and use case document sent to the
        IESG (Information)

      
 

      

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


    

    

    
-- 
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department 
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: spromano@unina.it
          http://www.comics.unina.it/simonpietro.romano

    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/



  


--------------070106080006030904070403--

From georg.mayer@huawei.com  Mon Jun  6 02:50:15 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5FC111E80EC for ; Mon,  6 Jun 2011 02:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.184
X-Spam-Level: 
X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdMgUWO+uBBn for ; Mon,  6 Jun 2011 02:50:13 -0700 (PDT)
Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by ietfa.amsl.com (Postfix) with ESMTP id 591E811E808C for ; Mon,  6 Jun 2011 02:50:13 -0700 (PDT)
Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMD0027J4NNB2@usaga01-in.huawei.com> for dispatch@ietf.org; Mon, 06 Jun 2011 04:50:11 -0500 (CDT)
Received: from laptopserver (chello062178012102.5.11.vie.surfer.at [62.178.12.102]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPA id <0LMD008DA4NL0E@usaga01-in.huawei.com> for dispatch@ietf.org; Mon, 06 Jun 2011 04:50:11 -0500 (CDT)
Date: Mon, 06 Jun 2011 11:50:12 +0200
From: Georg Mayer 
In-reply-to: <4DDA0388.60702@ericsson.com>
To: dispatch@ietf.org
Message-id: <002b01cc242f$21c408a0$654c19e0$%mayer@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/alternative; boundary="Boundary_(ID_4Oe4uzwfaKRQadFI79kT1w)"
Content-language: de
Thread-index: AcwZFbUVvPeLMQk7TPSX0YkyX/8hZQLGSWAg
References: <4DDA0388.60702@ericsson.com>
Subject: Re: [dispatch] charter proposal: SIP end-to-end Session Identifier
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jun 2011 09:50:16 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_4Oe4uzwfaKRQadFI79kT1w)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hello Salvatore,
 
Thanks for taking this forward - this is an important issue from 3GPP
perspective and it would be great to see this progressing. I fully support
your proposal.
 
Best regards,
Georg
 
 
 
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf
Of Salvatore Loreto
Sent: Montag, 23. Mai 2011 08:50
To: dispatch@ietf.org
Subject: [dispatch] charter proposal: SIP end-to-end Session Identifier
 
Hi there,
below a charter proposal for a new wg working on End-to-end Session
Identifier in SIP.

In an effort to make progress and to facilitate the discussion
we have also created an Internet Draft that captures, at a high level, 
the requirements and use cases.
(It was submitted by Paul E. Jones last Friday; here the link: 
http://www.ietf.org/id/draft-jones-ipmc-session-id-reqts-00.txt )

cheers
/Sal
 
 
End-to-end Session Identifier in SIP (charter proposal )
----------------------------------------------

The end-to-end Session Identifier in an SIP-based multimedia communication
refers to the ability
for endpoints, intermediate devices, and management and monitoring system to
identify
and correlate SIP messages and dialogs of the same higher-level end-to-end
"communication 
session" across multiple SIP devices and hops. 

Unfortunately, there are a number of factors that contribute to the fact
that the current
dialog identifiers as defined in SIP is not suitable for end-to-end session
identification.
Perhaps the most important factor worth describing is that in real-world 
deployments devices like Session Border Controllers (SBC) often change the
current call 
identifiers (e.g., the From-tag and To-tag that are used in conjunction with
the Call-ID header
to make the dialog-id) as the session signaling passes through.


An end-to-end Session Identifier should allow the possibility to identify
the communication session
from the point of origin, passing through any number of intermediaries, to
the ultimate point
of termination. It should have the same aim as the From-tag, To-tag and
Call-ID conjunction,
but should not be mangled by intermediaries. 

A SIP end-to-end Session Identifier has been considered as possible solution
of different use cases like 
troubleshooting, billing, session tracking, session recording, media and
signaling correlation, and so forth.
Some of these requirements have also been identified and come directly from
other existing 
working group within the RAI area (e.g. SIPRec, Splices).

Moreover, other SDOs have identified the need for SIP and H.323 to carry the
same "session ID" value(s)
so that it is possible identify a call end-to end even when performing inter
working between
protocols.


This group will first focus on a document that will identify, collect and
discuss all the 
requirements and the use cases that have been identified.
The document may identify the possibility to design a general mechanism or
the need
to design multiple purpose built identifiers. 
Once the needs are clear and identified, the working group will specify the
mechanism(s).


Specifically, the proposed working group will develop the following
deliverable:
1.	A requirement and use case document with key consideration for SIP
Session
End-to-End identifier. The document will discuss the possibility of
designing
a general mechanism or the needs to design multiple purpose build
identifier.
2.	Specification of new mechanism(s).

Goal and Milestone:
    October 2011 - Requirement and use case document sent to the IESG
(Information)
 

--Boundary_(ID_4Oe4uzwfaKRQadFI79kT1w)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT


Hello Salvatore,
 
Thanks for taking this forward – this is an important issue from 3GPP perspective and it would be great to see this progressing. I fully support your proposal.
 
Best regards,
Georg
 
 
 
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Salvatore Loreto
Sent: Montag, 23. Mai 2011 08:50
To: dispatch@ietf.org
Subject: [dispatch] charter proposal: SIP end-to-end Session Identifier
 
Hi there,
below a charter proposal for a new wg working on End-to-end Session Identifier in SIP.

In an effort to make progress and to facilitate the discussion
we have also created an Internet Draft that captures, at a high level, 
the requirements 
 and use 
ed by Paul E. Jones last Friday; here the link: 
http://www.ietf.org/id/draft-jones-ipmc-session-id-reqts-00.txt )

cheers
/Sal
 
 
End-to-end Session Identifier in SIP (charter proposal )
----------------------------------------------

The end-to-end Session Identifier in an SIP-based multimedia communication refers to the ability
for endpoints, intermediate devices, and management and monitoring system to identify
and correlate SIP messages and dialogs of the same higher-level end-to-end "communication 
session" across multiple SIP dev
 ices and
ely, there are a number of factors that contribute to the fact that the current
dialog identifiers as defined in SIP is not suitable for end-to-end session identification.
Perhaps the most important factor worth describing is that in real-world 
deployments devices like Session Border Controllers (SBC) often change the current call 
identifiers (e.g., the From-tag and To-tag that are used in conjunction with the Call-ID header
to make the dialog-id) as the session signaling passes through.


An end-to-end Session Identifier should allow the possibility to identify the communication session
from the point of origin, passing through any number of intermediaries, to the ultimate point
of termination. It should have the same aim as the From-tag, To-tag and Call-ID conjunction,
but should not be mangled by intermediaries. 

A SIP end-to-end Session Identifier has been considered as possible solution of different use cases like 
troubleshooting, billing, session tracking, session recording, media and signaling correlation, and so forth.
Some of these requirements have also been identified and come directly from other existing 
working group within the RAI area (e.g. SIPRec, Splices).

Moreover, other SDOs have identified the need for SIP and H.323 to carry the same "session ID" value(s)
so that it is possible identify a call end-to end even when performing inter working between
protocols.


This group will first focus on a document that will identify, collect and discuss all the 
requirements and the use cases that have been identified.
The document may identify the poss
 ibility 
nism or the need
to design multiple purpose built identifiers. 
Once the needs are clear and identified, the working group will specify the mechanism(s).


Specifically, the proposed working group will develop the following deliverable:
  1. A requirement and use case document with key consideration for SIP Session
    End-to-End identifier. The document will discuss the possibility of designing
    a general mechanism or the needs to design multiple purpose build identifier.
  2. Specification of new mechanism(s).

Goal and Milestone:
    October 2011 - Requirement and use case document sent to the IESG (Information)
 


--Boundary_(ID_4Oe4uzwfaKRQadFI79kT1w)--

From md3135@att.com  Mon Jun  6 07:16:15 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE1711E8153 for ; Mon,  6 Jun 2011 07:16:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.598
X-Spam-Level: 
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upgeicJkMyGH for ; Mon,  6 Jun 2011 07:16:12 -0700 (PDT)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 664A211E814D for ; Mon,  6 Jun 2011 07:16:12 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: md3135@att.com
X-Msg-Ref: server-9.tower-120.messagelabs.com!1307369770!21197752!1
X-StarScan-Version: 6.2.17; banners=-,-,-
X-Originating-IP: [144.160.20.146]
Received: (qmail 20038 invoked from network); 6 Jun 2011 14:16:11 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-9.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Jun 2011 14:16:11 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p56EF4U6001242 for ; Mon, 6 Jun 2011 10:15:04 -0400
Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p56EF364001232 for ; Mon, 6 Jun 2011 10:15:03 -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_01CC2454.47B95C7C"
Date: Mon, 6 Jun 2011 10:16:07 -0400
Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA0A39572B@gaalpa1msgusr7e.ugd.att.com>
In-Reply-To: <002b01cc242f$21c408a0$654c19e0$%mayer@huawei.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] charter proposal: SIP end-to-end Session Identifier
Thread-Index: AcwZFbUVvPeLMQk7TPSX0YkyX/8hZQLGSWAgAAlQ19A=
References: <4DDA0388.60702@ericsson.com> <002b01cc242f$21c408a0$654c19e0$%mayer@huawei.com>
From: "DOLLY, MARTIN C (ATTSI)" 
To: "Georg Mayer" , 
Subject: Re: [dispatch] charter proposal: SIP end-to-end Session Identifier
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jun 2011 14:16:15 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC2454.47B95C7C
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Greetings from Asbury Park,

=20

AT&T supports this work progressing and supports the proposal.

=20

Cheers,

=20

Martin

=20

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Georg Mayer
Sent: Monday, June 06, 2011 5:50 AM
To: dispatch@ietf.org
Subject: Re: [dispatch] charter proposal: SIP end-to-end Session
Identifier

=20

Hello Salvatore,

=20

Thanks for taking this forward - this is an important issue from 3GPP
perspective and it would be great to see this progressing. I fully
support your proposal.

=20

Best regards,

Georg

=20

=20

=20

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Salvatore Loreto
Sent: Montag, 23. Mai 2011 08:50
To: dispatch@ietf.org
Subject: [dispatch] charter proposal: SIP end-to-end Session Identifier

=20

Hi there,

below a charter proposal for a new wg working on End-to-end Session
Identifier in SIP.


In an effort to make progress and to facilitate the discussion
we have also created an Internet Draft that captures, at a high level,=20
the requirements and use ed by Paul E. Jones last Friday; here the link:

http://www.ietf.org/id/draft-jones-ipmc-session-id-reqts-00.txt )


cheers
/Sal

=20
=20

End-to-end Session Identifier in SIP (charter proposal )
----------------------------------------------


The end-to-end Session Identifier in an SIP-based multimedia
communication refers to the ability
for endpoints, intermediate devices, and management and monitoring
system to identify
and correlate SIP messages and dialogs of the same higher-level
end-to-end "communication=20
session" across multiple SIP dev ices and ely, there are a number of
factors that contribute to the fact that the current
dialog identifiers as defined in SIP is not suitable for end-to-end
session identification.
Perhaps the most important factor worth describing is that in real-world

deployments devices like Session Border Controllers (SBC) often change
the current call=20
identifiers (e.g., the From-tag and To-tag that are used in conjunction
with the Call-ID header
to make the dialog-id) as the session signaling passes through.



An end-to-end Session Identifier should allow the possibility to
identify the communication session
from the point of origin, passing through any number of intermediaries,
to the ultimate point
of termination. It should have the same aim as the From-tag, To-tag and
Call-ID conjunction,
but should not be mangled by intermediaries.=20


A SIP end-to-end Session Identifier has been considered as possible
solution of different use cases like=20
troubleshooting, billing, session tracking, session recording, media and
signaling correlation, and so forth.
Some of these requirements have also been identified and come directly
from other existing=20
working group within the RAI area (e.g. SIPRec, Splices).


Moreover, other SDOs have identified the need for SIP and H.323 to carry
the same "session ID" value(s)
so that it is possible identify a call end-to end even when performing
inter working between
protocols.


This group will first focus on a document that will identify, collect
and discuss all the=20
requirements and the use cases that have been identified.
The document may identify the poss ibility nism or the need
to design multiple purpose built identifiers.=20
Once the needs are clear and identified, the working group will specify
the mechanism(s).


Specifically, the proposed working group will develop the following
deliverable:

1.	A requirement and use case document with key consideration for
SIP Session
	End-to-End identifier. The document will discuss the possibility
of designing
	a general mechanism or the needs to design multiple purpose
build identifier.
2.	Specification of new mechanism(s).


Goal and Milestone:
    October 2011 - Requirement and use case document sent to the IESG
(Information)

=20


------_=_NextPart_001_01CC2454.47B95C7C
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Greetings from Asbury Park,
 
AT&T supports this work progressing and supports the =
proposal.
 
Cheers,
 
Martin
 
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On =
Behalf Of Georg Mayer
Sent: Monday, June 06, 2011 5:50 =
AM
To: dispatch@ietf.org
Subject: Re: [dispatch] =
charter proposal: SIP end-to-end Session =
Identifier
 
Hello Salvatore,
 
Thanks for taking this forward – this is an important issue =
from 3GPP perspective and it would be great to see this progressing. I =
fully support your proposal.
 
Best =
regards,
Georg
 
 
 
From:=
 dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On =
Behalf Of Salvatore Loreto
Sent: Montag, 23. Mai 2011 =
08:50
To: dispatch@ietf.org
Subject: [dispatch] =
charter proposal: SIP end-to-end Session =
Identifier
 
Hi =
there,
below a =
charter proposal for a new wg working on End-to-end Session Identifier =
in SIP.

In an effort to make =
progress and to facilitate the discussion
we have also created an =
Internet Draft that captures, at a high level, 
the requirements and =
use ed by Paul E. Jones last Friday; here the link: 
=
http://www.ietf.org/id/draft-jones-ipmc-session-id-reqts-00.txt =
)

cheers/Sal
 
 
End-to-end =
Session Identifier in SIP (charter proposal =
)
----------------------------------------------

The =
end-to-end Session Identifier in an SIP-based multimedia communication =
refers to the ability
for endpoints, intermediate devices, and =
management and monitoring system to identify
and correlate SIP =
messages and dialogs of the same higher-level end-to-end =
"communication 
session" across multiple SIP dev ices and =
ely, there are a number of factors that contribute to the fact that the =
current
dialog identifiers as defined in SIP is not suitable for =
end-to-end session identification.
Perhaps the most important factor =
worth describing is that in real-world 
deployments devices like =
Session Border Controllers (SBC) often change the current call =

identifiers (e.g., the From-tag and To-tag that are used in =
conjunction with the Call-ID header
to make the dialog-id) as the =
session signaling passes through.


An =
end-to-end Session Identifier should allow the possibility to identify =
the communication session
from the point of origin, passing through =
any number of intermediaries, to the ultimate point
of termination. =
It should have the same aim as the From-tag, To-tag and Call-ID =
conjunction,
but should not be mangled by intermediaries. =


A SIP end-to-end Session Identifier has been =
considered as possible solution of =
different use cases like 
troubleshooting, billing, session tracking, =
session recording, media and signaling correlation, and so =
forth.
Some of these requirements have also been identified and come =
directly from other existing 
working group within the RAI area (e.g. =
SIPRec, Splices).

Moreover=
, other SDOs have identified the =
need for SIP and H.323 to carry the same "session ID" =
value(s)
so that it is possible identify a call end-to end even when =
performing inter working between
protocols.


This group =
will first focus on a document that will identify, collect and discuss =
all the 
requirements and the use cases that have been =
identified.
The document may identify the poss ibility nism or the =
need
to design multiple purpose built identifiers. 
Once the needs =
are clear and identified, the working group will specify the =
mechanism(s).


Specifically, the proposed working group will =
develop the following deliverable:
  1. A requirement and use case document with key consideration =
for SIP Session
    End-to-End identifier. The document will discuss the =
possibility of designing
    a general mechanism or the needs to design =
multiple purpose build identifier.
  2. Specification of new mechanism(s).

Goal and Milestone:
    October =
2011 - Requirement and use case document sent to the IESG =
(Information)
 <=
/o:p>

------_=_NextPart_001_01CC2454.47B95C7C--

From christer.holmberg@ericsson.com  Mon Jun  6 07:49:47 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F001411E8145 for ; Mon,  6 Jun 2011 07:49:47 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ypp9tvKr9w8v for ; Mon,  6 Jun 2011 07:49:46 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8D43711E80FE for ; Mon,  6 Jun 2011 07:49:46 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c17ae00000262e-4e-4dece9091a7f
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BB.32.09774.909ECED4; Mon,  6 Jun 2011 16:49:45 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 6 Jun 2011 16:49:45 +0200
From: Christer Holmberg 
To: Salvatore Loreto , "dispatch@ietf.org" 
Date: Mon, 6 Jun 2011 16:49:12 +0200
Thread-Topic: [dispatch] charter proposal: SIP end-to-end Session Identifier
Thread-Index: AcwZFZ+bx90UrQp7QFSy0LVEKTLc8gLQ0baa
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A415@ESESSCMS0356.eemea.ericsson.se>
References: <4DDA0388.60702@ericsson.com>
In-Reply-To: <4DDA0388.60702@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [dispatch] charter proposal: SIP end-to-end Session Identifier
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jun 2011 14:49:48 -0000

Hi,

I support the charter proposal. I think this is an important feature.

Regards,

Christer

________________________________
From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Sa=
lvatore Loreto [salvatore.loreto@ericsson.com]
Sent: Monday, May 23, 2011 9:49 AM
To: dispatch@ietf.org
Subject: [dispatch] charter proposal: SIP end-to-end Session Identifier

Hi there,
below a charter proposal for a new wg working on End-to-end Session Identif=
ier in SIP.

In an effort to make progress and to facilitate the discussion
we have also created an Internet Draft that captures, at a high level,
the requirements and use cases.
(It was submitted by Paul E. Jones last Friday; here the link:
http://www.ietf.org/id/draft-jones-ipmc-session-id-reqts-00.txt )

cheers
/Sal
End-to-end Session Identifier in SIP (charter proposal )
----------------------------------------------

The end-to-end Session Identifier in an SIP-based multimedia communication =
refers to the ability
for endpoints, intermediate devices, and management and monitoring system t=
o identify
and correlate SIP messages and dialogs of the same higher-level end-to-end =
"communication
session" across multiple SIP devices and hops.

Unfortunately, there are a number of factors that contribute to the fact th=
at the current
dialog identifiers as defined in SIP is not suitable for end-to-end session=
 identification.
Perhaps the most important factor worth describing is that in real-world
deployments devices like Session Border Controllers (SBC) often change the =
current call
identifiers (e.g., the From-tag and To-tag that are used in conjunction wit=
h the Call-ID header
to make the dialog-id) as the session signaling passes through.


An end-to-end Session Identifier should allow the possibility to identify t=
he communication session
from the point of origin, passing through any number of intermediaries, to =
the ultimate point
of termination. It should have the same aim as the From-tag, To-tag and Cal=
l-ID conjunction,
but should not be mangled by intermediaries.

A SIP end-to-end Session Identifier has been considered as possible solutio=
n of different use cases like
troubleshooting, billing, session tracking, session recording, media and si=
gnaling correlation, and so forth.
Some of these requirements have also been identified and come directly from=
 other existing
working group within the RAI area (e.g. SIPRec, Splices).

Moreover, other SDOs have identified the need for SIP and H.323 to carry th=
e same "session ID" value(s)
so that it is possible identify a call end-to end even when performing inte=
r working between
protocols.


This group will first focus on a document that will identify, collect and d=
iscuss all the
requirements and the use cases that have been identified.
The document may identify the possibility to design a general mechanism or =
the need
to design multiple purpose built identifiers.
Once the needs are clear and identified, the working group will specify the=
 mechanism(s).


Specifically, the proposed working group will develop the following deliver=
able:

 1.  A requirement and use case document with key consideration for SIP Ses=
sion
End-to-End identifier. The document will discuss the possibility of designi=
ng
a general mechanism or the needs to design multiple purpose build identifie=
r.
 2.  Specification of new mechanism(s).

Goal and Milestone:
    October 2011 - Requirement and use case document sent to the IESG (Info=
rmation)


From richard@shockey.us  Mon Jun  6 09:11:21 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DD621F84A1 for ; Mon,  6 Jun 2011 09:11:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Level: 
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nI8sNUhJK18E for ; Mon,  6 Jun 2011 09:11:21 -0700 (PDT)
Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 3354821F84A4 for ; Mon,  6 Jun 2011 09:11:19 -0700 (PDT)
Received: (qmail 16872 invoked by uid 0); 6 Jun 2011 16:11:18 -0000
Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 6 Jun 2011 16:11:18 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=WhG6K0N19wBrmbTRAhEYRFdYMaH4rdN0dkzRC1hlFtfqq+Ddi7AONUTX1qL+POCN3vzr2Cv4t1HVJRP015PfTU8wpAUlFuaNwy2AaBbEKe9W5PJHrfAz2UNnoLD9SrPF;
Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1QTcOb-0001sG-IG for dispatch@ietf.org; Mon, 06 Jun 2011 10:11:17 -0600
From: "Richard Shockey" 
To: 
References: <4DDA0388.60702@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A415@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A415@ESESSCMS0356.eemea.ericsson.se>
Date: Mon, 6 Jun 2011 12:11:17 -0400
Message-ID: <006501cc2464$5e4f5a10$1aee0e30$@us>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcwZFZ+bx90UrQp7QFSy0LVEKTLc8gLQ0baaAALaZkA=
Content-Language: en-us
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us}
Subject: Re: [dispatch] charter proposal: SIP end-to-end Session Identifier
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jun 2011 16:11:21 -0000

Long Long overdue ..  +1 

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf
Of Christer Holmberg
Sent: Monday, June 06, 2011 10:49 AM
To: Salvatore Loreto; dispatch@ietf.org
Subject: Re: [dispatch] charter proposal: SIP end-to-end Session Identifier

Hi,

I support the charter proposal. I think this is an important feature.

Regards,

Christer

________________________________
From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of
Salvatore Loreto [salvatore.loreto@ericsson.com]
Sent: Monday, May 23, 2011 9:49 AM
To: dispatch@ietf.org
Subject: [dispatch] charter proposal: SIP end-to-end Session Identifier

Hi there,
below a charter proposal for a new wg working on End-to-end Session
Identifier in SIP.

In an effort to make progress and to facilitate the discussion
we have also created an Internet Draft that captures, at a high level,
the requirements and use cases.
(It was submitted by Paul E. Jones last Friday; here the link:
http://www.ietf.org/id/draft-jones-ipmc-session-id-reqts-00.txt )

cheers
/Sal
End-to-end Session Identifier in SIP (charter proposal )
----------------------------------------------

The end-to-end Session Identifier in an SIP-based multimedia communication
refers to the ability
for endpoints, intermediate devices, and management and monitoring system to
identify
and correlate SIP messages and dialogs of the same higher-level end-to-end
"communication
session" across multiple SIP devices and hops.

Unfortunately, there are a number of factors that contribute to the fact
that the current
dialog identifiers as defined in SIP is not suitable for end-to-end session
identification.
Perhaps the most important factor worth describing is that in real-world
deployments devices like Session Border Controllers (SBC) often change the
current call
identifiers (e.g., the From-tag and To-tag that are used in conjunction with
the Call-ID header
to make the dialog-id) as the session signaling passes through.


An end-to-end Session Identifier should allow the possibility to identify
the communication session
from the point of origin, passing through any number of intermediaries, to
the ultimate point
of termination. It should have the same aim as the From-tag, To-tag and
Call-ID conjunction,
but should not be mangled by intermediaries.

A SIP end-to-end Session Identifier has been considered as possible solution
of different use cases like
troubleshooting, billing, session tracking, session recording, media and
signaling correlation, and so forth.
Some of these requirements have also been identified and come directly from
other existing
working group within the RAI area (e.g. SIPRec, Splices).

Moreover, other SDOs have identified the need for SIP and H.323 to carry the
same "session ID" value(s)
so that it is possible identify a call end-to end even when performing inter
working between
protocols.


This group will first focus on a document that will identify, collect and
discuss all the
requirements and the use cases that have been identified.
The document may identify the possibility to design a general mechanism or
the need
to design multiple purpose built identifiers.
Once the needs are clear and identified, the working group will specify the
mechanism(s).


Specifically, the proposed working group will develop the following
deliverable:

 1.  A requirement and use case document with key consideration for SIP
Session
End-to-End identifier. The document will discuss the possibility of
designing
a general mechanism or the needs to design multiple purpose build
identifier.
 2.  Specification of new mechanism(s).

Goal and Milestone:
    October 2011 - Requirement and use case document sent to the IESG
(Information)

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


From dworley@avaya.com  Mon Jun  6 12:37:33 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D211F0C4C for ; Mon,  6 Jun 2011 12:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7d7bQEgkCDmL for ; Mon,  6 Jun 2011 12:37:32 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 715551F0C44 for ; Mon,  6 Jun 2011 12:37:32 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EANAq7U2HCzI1/2dsb2JhbABTpiZ3rhECm0GGIQSVXopx
X-IronPort-AV: E=Sophos;i="4.65,327,1304308800"; d="scan'208";a="283504058"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Jun 2011 15:37:31 -0400
X-IronPort-AV: E=Sophos;i="4.65,327,1304308800"; d="scan'208";a="660031089"
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 Jun 2011 15:37:31 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Mon, 6 Jun 2011 15:37:31 -0400
From: "Worley, Dale R (Dale)" 
To: Shida Schubert , James M.Polk 
Date: Mon, 6 Jun 2011 15:36:53 -0400
Thread-Topic: [dispatch] Emergency Text Messaging using SIP MESSAGE
Thread-Index: AcwguLbyYYYvqjSjQIy+xIhwaW9uFQDyF/VS
Message-ID: 
References: <30E0133A-9869-41B1-BCB2-B32E369D7ABB@cs.columbia.edu> <201105302334.p4UNYgSj010236@mtv-core-2.cisco.com>, <1D7207A8-5FAE-4D59-8F6E-1855B10C3BB8@ntt-at.com>
In-Reply-To: <1D7207A8-5FAE-4D59-8F6E-1855B10C3BB8@ntt-at.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dispatch@ietf.org" , Jong Yul Kim 
Subject: Re: [dispatch] Emergency Text Messaging using SIP MESSAGE
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jun 2011 19:37:33 -0000

________________________________________
From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Sh=
ida Schubert [shida@ntt-at.com]

Also, although I haven't gone through this draft, ECRIT
already has a draft discussing the use of MESSAGE method
in the context of emergency call.

http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-01
_______________________________________________

Though I see that this draft does not envision a series of MESSAGE requests=
, only a single request.

Dale

From musgravepj@gmail.com  Mon Jun  6 16:40:42 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8421F0C46 for ; Mon,  6 Jun 2011 16:40:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.953
X-Spam-Level: 
X-Spam-Status: No, score=-2.953 tagged_above=-999 required=5 tests=[AWL=0.645,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T68FNqIrNb6g for ; Mon,  6 Jun 2011 16:40:41 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 528F61F0C4D for ; Mon,  6 Jun 2011 16:40:41 -0700 (PDT)
Received: by mail-fx0-f44.google.com with SMTP id 15so3181102fxm.31 for ; Mon, 06 Jun 2011 16:40:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UoU0ZZpzfUC8xBmenBF7bpDphyRGRYVnEjyhnyWEkvQ=; b=HHycM4KSOSEPDddcncG+ehhGz2mLo5kInljePX+8DQIu43TK6AAD3mVQOw2C8OUX/Z fDw96XE9jasY2mnYm68ZXLSfKOycI/EMWEOP2WOV6DCoR32cKeleAF21wRPfOMQ5eGPP u2fQgb9GfMXp5ZFW3nC8ur04LegYTM7sKb9ik=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OS8kLxxA6NIHi6Mq4fGNgk8GXA7LFdiFLtnA1kEJGkLPfp7lqPbVV/6KmUzwVoCint Ps5cJpGPVS9JzkOl5D2flrHo5d//+iKCgpV4PrwI4q+1TNQU2sWPTSJC4QTjf8nJTYHx HpIM8SN19XsxB+flK2TTW3EauYItvggIdPLAI=
MIME-Version: 1.0
Received: by 10.223.127.210 with SMTP id h18mr1744496fas.46.1307403640921; Mon, 06 Jun 2011 16:40:40 -0700 (PDT)
Received: by 10.223.143.71 with HTTP; Mon, 6 Jun 2011 16:40:40 -0700 (PDT)
In-Reply-To: <006501cc2464$5e4f5a10$1aee0e30$@us>
References: <4DDA0388.60702@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A415@ESESSCMS0356.eemea.ericsson.se> <006501cc2464$5e4f5a10$1aee0e30$@us>
Date: Mon, 6 Jun 2011 19:40:40 -0400
Message-ID: 
From: Peter Musgrave 
To: Richard Shockey 
Content-Type: multipart/alternative; boundary=002354530970985fa704a513a1bd
Cc: dispatch@ietf.org
Subject: Re: [dispatch] charter proposal: SIP end-to-end Session Identifier
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jun 2011 23:40:42 -0000

--002354530970985fa704a513a1bd
Content-Type: text/plain; charset=ISO-8859-1

+1

Peter Musgrave

On Mon, Jun 6, 2011 at 12:11 PM, Richard Shockey  wrote:

> Long Long overdue ..  +1
>
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf
> Of Christer Holmberg
> Sent: Monday, June 06, 2011 10:49 AM
> To: Salvatore Loreto; dispatch@ietf.org
> Subject: Re: [dispatch] charter proposal: SIP end-to-end Session Identifier
>
> Hi,
>
> I support the charter proposal. I think this is an important feature.
>
> Regards,
>
> Christer
>
> ________________________________
> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of
> Salvatore Loreto [salvatore.loreto@ericsson.com]
> Sent: Monday, May 23, 2011 9:49 AM
> To: dispatch@ietf.org
> Subject: [dispatch] charter proposal: SIP end-to-end Session Identifier
>
> Hi there,
> below a charter proposal for a new wg working on End-to-end Session
> Identifier in SIP.
>
> In an effort to make progress and to facilitate the discussion
> we have also created an Internet Draft that captures, at a high level,
> the requirements and use cases.
> (It was submitted by Paul E. Jones last Friday; here the link:
> http://www.ietf.org/id/draft-jones-ipmc-session-id-reqts-00.txt )
>
> cheers
> /Sal
> End-to-end Session Identifier in SIP (charter proposal )
> ----------------------------------------------
>
> The end-to-end Session Identifier in an SIP-based multimedia communication
> refers to the ability
> for endpoints, intermediate devices, and management and monitoring system
> to
> identify
> and correlate SIP messages and dialogs of the same higher-level end-to-end
> "communication
> session" across multiple SIP devices and hops.
>
> Unfortunately, there are a number of factors that contribute to the fact
> that the current
> dialog identifiers as defined in SIP is not suitable for end-to-end session
> identification.
> Perhaps the most important factor worth describing is that in real-world
> deployments devices like Session Border Controllers (SBC) often change the
> current call
> identifiers (e.g., the From-tag and To-tag that are used in conjunction
> with
> the Call-ID header
> to make the dialog-id) as the session signaling passes through.
>
>
> An end-to-end Session Identifier should allow the possibility to identify
> the communication session
> from the point of origin, passing through any number of intermediaries, to
> the ultimate point
> of termination. It should have the same aim as the From-tag, To-tag and
> Call-ID conjunction,
> but should not be mangled by intermediaries.
>
> A SIP end-to-end Session Identifier has been considered as possible
> solution
> of different use cases like
> troubleshooting, billing, session tracking, session recording, media and
> signaling correlation, and so forth.
> Some of these requirements have also been identified and come directly from
> other existing
> working group within the RAI area (e.g. SIPRec, Splices).
>
> Moreover, other SDOs have identified the need for SIP and H.323 to carry
> the
> same "session ID" value(s)
> so that it is possible identify a call end-to end even when performing
> inter
> working between
> protocols.
>
>
> This group will first focus on a document that will identify, collect and
> discuss all the
> requirements and the use cases that have been identified.
> The document may identify the possibility to design a general mechanism or
> the need
> to design multiple purpose built identifiers.
> Once the needs are clear and identified, the working group will specify the
> mechanism(s).
>
>
> Specifically, the proposed working group will develop the following
> deliverable:
>
>  1.  A requirement and use case document with key consideration for SIP
> Session
> End-to-End identifier. The document will discuss the possibility of
> designing
> a general mechanism or the needs to design multiple purpose build
> identifier.
>  2.  Specification of new mechanism(s).
>
> Goal and Milestone:
>    October 2011 - Requirement and use case document sent to the IESG
> (Information)
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

--002354530970985fa704a513a1bd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1

Peter Musgrave

On M=
on, Jun 6, 2011 at 12:11 PM, Richard Shockey <richard@shockey.us> wrote:
=


Long Long overdue .. =A0+1



-----Original Message-----

From: dispatch-bounces@ietf.or=
g [mailto:dispatch-bounces=
@ietf.org] On Behalf

Of Christer Holmberg

Sent: Monday, June 06, 2011 10:49 AM

To: Salvatore Loreto; dispatch@ietf.or=
g

Subject: Re: [dispatch] charter proposal: SIP end-to-end Session Identifier=





Hi,



I support the charter proposal. I think this is an important feature.



Regards,



Christer



________________________________

From: dispatch-bounces@ietf.or=
g [dispatch-bounces@ietf.o=
rg] On Behalf Of

Salvatore Loreto [salvator=
e.loreto@ericsson.com]

Sent: Monday, May 23, 2011 9:49 AM

To: dispatch@ietf.org

Subject: [dispatch] charter proposal: SIP end-to-end Session Identifier



Hi there,

below a charter proposal for a new wg working on End-to-end Session

Identifier in SIP.



In an effort to make progress and to facilitate the discussion

we have also created an Internet Draft that captures, at a high level,

the requirements and use cases.

(It was submitted by Paul E. Jones last Friday; here the link:

http://www.ietf.org/id/draft-jones-ipmc-session-id-reqts=
-00.txt )



cheers

/Sal

End-to-end Session Identifier in SIP (charter proposal )

----------------------------------------------



The end-to-end Session Identifier in an SIP-based multimedia communication<=
br>
refers to the ability

for endpoints, intermediate devices, and management and monitoring system t=
o

identify

and correlate SIP messages and dialogs of the same higher-level end-to-end<=
br>
"communication

session" across multiple SIP devices and hops.



Unfortunately, there are a number of factors that contribute to the fact
that the current

dialog identifiers as defined in SIP is not suitable for end-to-end session=


identification.

Perhaps the most important factor worth describing is that in real-world
deployments devices like Session Border Controllers (SBC) often change the<=
br>
current call

identifiers (e.g., the From-tag and To-tag that are used in conjunction wit=
h

the Call-ID header

to make the dialog-id) as the session signaling passes through.





An end-to-end Session Identifier should allow the possibility to identify
the communication session

from the point of origin, passing through any number of intermediaries, to<=
br>
the ultimate point

of termination. It should have the same aim as the From-tag, To-tag and

Call-ID conjunction,

but should not be mangled by intermediaries.



A SIP end-to-end Session Identifier has been considered as possible solutio=
n

of different use cases like

troubleshooting, billing, session tracking, session recording, media and
signaling correlation, and so forth.

Some of these requirements have also been identified and come directly from=


other existing

working group within the RAI area (e.g. SIPRec, Splices).



Moreover, other SDOs have identified the need for SIP and H.323 to carry th=
e

same "session ID" value(s)

so that it is possible identify a call end-to end even when performing inte=
r

working between

protocols.





This group will first focus on a document that will identify, collect and
discuss all the

requirements and the use cases that have been identified.

The document may identify the possibility to design a general mechanism or<=
br>
the need

to design multiple purpose built identifiers.

Once the needs are clear and identified, the working group will specify the=


mechanism(s).





Specifically, the proposed working group will develop the following

deliverable:



=A01. =A0A requirement and use case document with key consideration for SIP=


Session

End-to-End identifier. The document will discuss the possibility of

designing

a general mechanism or the needs to design multiple purpose build

identifier.

=A02. =A0Specification of new mechanism(s).



Goal and Milestone:

 =A0 =A0October 2011 - Requirement and use case document sent to the IESG
(Information)



_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch



_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch





--002354530970985fa704a513a1bd--

From laura.liess.dt@googlemail.com  Mon Jun  6 23:44:21 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59E011E8081 for ; Mon,  6 Jun 2011 23:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYA8-fxKG5kB for ; Mon,  6 Jun 2011 23:44:21 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F206411E807B for ; Mon,  6 Jun 2011 23:44:20 -0700 (PDT)
Received: by vws12 with SMTP id 12so4221774vws.31 for ; Mon, 06 Jun 2011 23:44:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=H+1iv7qJ4t0mw4pUj6QJ1aDFmAkdsG1E6zm/ThnlWGM=; b=hdaZXpVvZeaEKZ82xuENt3onj1l8xtMYUOLFr/CjHVIVfKN4plc7cV1szNdwGVliqW 0DOw9X/jzUIh7zR13yDcsnTd523M3xv2QmLHicO6Rp9YEHW31w9eTzV6HeYnvLE8GfyU 35liVj08Sq5YX0S0jzDMa4XRqqzHlKO0kmyjQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XbF89q/R85KDzJvoJ5BMsQzfkeoATbSZ1e5lz7jgo6J0CEd9tygwKeRXwMn1mQ8GfU Vwb73vVUsJwvwUbq0DuKqKw/VHY2u8oAoO5lU/Hz87kwxcMmpMiRCanTzZGUKz5CCx1Z 9GB7Li7WA6TvyznEImFarSmDy5VwkolGSVGE0=
MIME-Version: 1.0
Received: by 10.52.97.33 with SMTP id dx1mr7658046vdb.34.1307429058951; Mon, 06 Jun 2011 23:44:18 -0700 (PDT)
Received: by 10.52.111.35 with HTTP; Mon, 6 Jun 2011 23:44:18 -0700 (PDT)
In-Reply-To: <4DDA0388.60702@ericsson.com>
References: <4DDA0388.60702@ericsson.com>
Date: Tue, 7 Jun 2011 08:44:18 +0200
Message-ID: 
From: Laura Liess 
To: Salvatore Loreto 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] charter proposal: SIP end-to-end Session Identifier
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jun 2011 06:44:22 -0000

Sal,

Thank you for for doing this work. As Richard already wrote, it's long
overdue.

I am willing to contribute to take this issue forward. I read the
charter and it is OK for me. At some point in time, when it is more
clear how many documents we need to specify the mechanism(s), we will
need to add  one or more additional  milestones for these documents.

Thanks
Laura

2011/5/23 Salvatore Loreto :
> Hi there,
>
> below a charter proposal for a new wg working on End-to-end Session
> Identifier in SIP.
>
> In an effort to make progress and to facilitate the discussion
> we have also created an Internet Draft that captures, at a high level,
> the requirements and use cases.
> (It was submitted by Paul E. Jones last Friday; here the link:
> http://www.ietf.org/id/draft-jones-ipmc-session-id-reqts-00.txt )
>
> cheers
> /Sal
>
> End-to-end Session Identifier in SIP (charter proposal )
> ----------------------------------------------
>
> The end-to-end Session Identifier in an SIP-based multimedia communicatio=
n
> refers to the ability
> for endpoints, intermediate devices, and management and monitoring system=
 to
> identify
> and correlate SIP messages and dialogs of the same higher-level end-to-en=
d
> "communication
> session" across multiple SIP devices and hops.
>
> Unfortunately, there are a number of factors that contribute to the fact
> that the current
> dialog identifiers as defined in SIP is not suitable for end-to-end sessi=
on
> identification.
> Perhaps the most important factor worth describing is that in real-world
> deployments devices like Session Border Controllers (SBC) often change th=
e
> current call
> identifiers (e.g., the From-tag and To-tag that are used in conjunction w=
ith
> the Call-ID header
> to make the dialog-id) as the session signaling passes through.
>
> An end-to-end Session Identifier should allow the possibility to identify
> the communication session
> from the point of origin, passing through any number of intermediaries, t=
o
> the ultimate point
> of termination. It should have the same aim as the From-tag, To-tag and
> Call-ID conjunction,
> but should not be mangled by intermediaries.
>
> A SIP end-to-end Session Identifier has been considered as possible solut=
ion
> of different use cases like
> troubleshooting, billing, session tracking, session recording, media and
> signaling correlation, and so forth.
> Some of these requirements have also been identified and come directly fr=
om
> other existing
> working group within the RAI area (e.g. SIPRec, Splices).
>
> Moreover, other SDOs have identified the need for SIP and H.323 to carry =
the
> same "session ID" value(s)
> so that it is possible identify a call end-to end even when performing in=
ter
> working between
> protocols.
>
>
> This group will first focus on a document that will identify, collect and
> discuss all the
> requirements and the use cases that have been identified.
> The document may identify the possibility to design a general mechanism o=
r
> the need
> to design multiple purpose built identifiers.
> Once the needs are clear and identified, the working group will specify t=
he
> mechanism(s).
>
>
> Specifically, the proposed working group will develop the following
> deliverable:
>
> A requirement and use case document with key consideration for SIP Sessio=
n
> End-to-End identifier. The document will discuss the possibility of
> designing
> a general mechanism or the needs to design multiple purpose build
> identifier.
> Specification of new mechanism(s).
>
> Goal and Milestone:
> =A0=A0=A0 October 2011 - Requirement and use case document sent to the IE=
SG
> (Information)
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
>

From bruno.chatras@orange-ftgroup.com  Tue Jun  7 02:13:51 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5379621F8607 for ; Tue,  7 Jun 2011 02:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.21
X-Spam-Level: 
X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[AWL=1.039,  BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H39T0xZLB5-5 for ; Tue,  7 Jun 2011 02:13:48 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id E60E121F8602 for ; Tue,  7 Jun 2011 02:13:47 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 05623FC4012; Tue,  7 Jun 2011 11:13:47 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id E30F6FC400C; Tue,  7 Jun 2011 11:13:46 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 7 Jun 2011 11:13:46 +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_01CC24F3.3456C88A"
Date: Tue, 7 Jun 2011 11:13:45 +0200
Message-ID: <9ECCF01B52E7AB408A7EB8535264214102EE636C@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] SIP Load balancing (SIPLB) Charter proposal
Thread-Index: AcwZVtBeNaZm1dRbQuqPlztWqYWALQAA7TCwADcJ4MAAFrdSIAKX5sGQ
References:  <9ECCF01B52E7AB408A7EB8535264214102E4435E@ftrdmel0.rd.francetelecom.fr> 
From: 
To: , 
X-OriginalArrivalTime: 07 Jun 2011 09:13:46.0841 (UTC) FILETIME=[34CD1490:01CC24F3]
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jun 2011 09:13:51 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC24F3.3456C88A
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=20

=20

De : Parthasarathi R (partr) [mailto:partr@cisco.com]=20
Envoy=E9 : mercredi 25 mai 2011 06:24
=C0 : CHATRAS Bruno RD-CORE-ISS; dispatch@ietf.org
Objet : RE: [dispatch] SIP Load balancing (SIPLB) Charter proposal

=20

Hi Bruno,

=20

Thanks for your interest in the charter. Please read inline.

=20

Thanks

Partha

=20

________________________________

From: bruno.chatras@orange-ftgroup.com =
[mailto:bruno.chatras@orange-ftgroup.com]=20
Sent: Tuesday, May 24, 2011 11:00 PM
To: Parthasarathi R (partr); dispatch@ietf.org
Subject: RE: [dispatch] SIP Load balancing (SIPLB) Charter proposal

Hi all,

=20

1 comment and 1 question

=20

Comment: In the list of considerations that must be taken into account I =
would add =AB Whether the load balancer is SIP-aware or not.

=20

 Till now, we are discussing about SIP-aware load balancer only. =
In case the load balancer is SIP-unaware, is it something like =
load-balance by open-loop model wherein there is no feedback required =
from downstream servers or load balance in the transport layer instead =
of SIP layer ?. Could you please explain your consideration in detail. =


[BC] I was referring to a load balancer at the transport layer with =
feedback from downstream servers.

=20

Question: Is the Charter intended to cover architectures with an in-path =
load balancer in front of a farm of SIP servers only or is it expected =
to cover as well other architectures where the load balancer is off-path =
or even architectures where load balancing just relies on frequent =
updates of the DNS?=20

  The charter's first consideration explains open-loop model. =
So, it might be possible to get the solution through open-loop model =
(off-path). ISTM, DNS update for load balancer also falls under =
open-loop model until otherwise DNS weight and priority varies so often =
based on system load but it is next to impossible to change DNS so =
frequently in the real-time. 

[BC] I was indeed referring to solutions where the DNS is frequently =
updated (weight and priority) using RFC 2136. Note that there are =
architectures where the DNS is not directly updated by the SIP servers =
but by an intermediate entity (see e.g. the LDF in =
http://www.3gpp.org/ftp/Specs/archive/23_series/23.812/23812-115.zip)

=20

=20

I guess that 1st consideration will=20

=20

Bruno

=20

=20

=20

=20

De : dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] De la =
part de Parthasarathi R (partr)
Envoy=E9 : lundi 23 mai 2011 17:04
=C0 : dispatch@ietf.org
Objet : [dispatch] SIP Load balancing (SIPLB) Charter proposal

=20

Hi all,

=20

Charter proposal for SIP load balancing (SIPLB) is written in this mail =
to create a new WG related to SIP based load balancing.

=20

There are lot of interest in SIP load balancing work during the time of =
IETF-80 and the side meeting leads to the creation of this charter. =
There are lot of draft submitted in Dispatch related to this work and =
the list is as follows:

=20

[1]http://tools.ietf.org/html/draft-bessis-dispatch-adaptive-load-balanci=
ng-00
[2]http://tools.ietf.org/html/draft-jones-sip-overload-sce-00
[3]http://tools.ietf.org/html/draft-partha-dispatch-sip-media-overload-co=
ntrol-00

=20

To make the progress in the work, the charter currently focus on two =
types of SIP based load balancing namely signaling only SIP load =
balancing and Media-related SIP based load balancing.=20

=20

Please provide your value inputs and comments in the below charter.

=20

Thanks

Vijay/Partha

=20

SIP Load balancing (SIPLB) Charter
----------------------------------
=20
Session Load balancing (SIPLB) working group is chartered to define a=20
SIP-based protocol for load balancing SIP sessions.
=20
Load balancing across a farm of SIP servers can be done today, but =
without=20
generally agreed upon principles on how to best do accomplish this.
Confounding the problem is that a SIP farm may consist of hosts with=20
varying capabilities, example, a SIP proxy, a back-to-back user agent=20
(B2BUA), a public-switched telephone system (PSTN) gateway, SIP Media=20
servers etc. The capabilities and processing capacity on hosts in the =
farm=20
may be different, sometimes vastly, from each other.  Furthermore, the=20
duration of time that a SIP host requires to process a SIP request=20
may vary. SIP proxies, operating at the transaction layer, may be=20
more efficient at processing transactions than a B2BUA would be,=20
which may need to maintain a long-lived dialogue state in addition to=20
the transaction state.  PSTN gateways may have other limitations such=20
as media resources that may be depleted even though the gateway may=20
have enough processing power (i.e., CPU) to handle incoming requests.
=20
In face of such diversity, simple load balancing schemes based on=20
round-robin selection tend to work only when many assumptions are met.
First, the relative capacity and processing resources of all SIP servers =

in the farm should be nearly equal.  Furthermore, because a round-robin=20
scheme presents a load of (1/n)*N to each server, where n =3D number of=20
servers and N =3D arrival rate in requests per second, it assumes that=20
the service time at each server is such that the utilization of each=20
server is not negatively impacted (i.e., utilization ratio of the =
arrival=20
rate over the mean service rate is less than 1.0).  And finally,=20
the round-robin load balancing does not have a backward feedback =
mechanism=20
whereby the load-balanced server can inform the load balancer of its=20
current utilization (i.e., round-robin load balancing acts as an =
open-loop=20
controller).
=20
The SIP load balancing working group is, therefore, chartered to=20
arrive at a load balancing scheme that distributes SIP requests to=20
a collection of servers to effectively utilize the resources at those=20
servers. These resources can include CPU, memory, network bandwidth,=20
input/output, DSP, DS0 or disk resources.  The load balancing
scheme must prevent excessive oscillation in the collection of
servers.

=20

In order to achieve such a load balancing scheme in practice, the =
following=20
considerations must be taken in account:
=20
1) Should the load balancing scheme have a closed-loop model, i.e.,=20
should it report utilization to the load balancer to allow the=20
load balancer to distribute requests proportionally?
=20
2) What should the diversity of the SIP hosts in a farm be?  Is=20
it reasonable to assume that the same load balancing scheme should=20
be applicable to a pair of SIP servers, one of which can handle=20
an order of magnitude more requests per unit time that the other?
=20
3) What information must be provisioned into the load balancer and=20
the servers?
=20
4) As SIP request resource consumption in SIP signaling only server=20
varies drastically from SIP media servers, should the solution be=20
split such that load balancing of a pure signaling server is different=20
than that of a SIP server that handles signaling as well as media?
=20
The last consideration above is especially important since a solution
to load balancing a media farm will require a model where the SIP=20
load balancer is closely coupled with the downstream SIP servers.
In such a model, the SIP load balancer knows the resources available
at each of the downstream SIP servers and is able to inspect an
incoming request to determine its media-related requirements and thus
dispatch it to the downstream SIP server that has the highest
probability of servicing that request.  In some architectures, such
a coupling reduces post-dial delay. =20

=20

Keeping the SIP load balancer and the downstream SIP servers=20
loosely coupled suffices for load balancing to a farm of SIP
servers that only handle signaling.  A loosely coupled model
operates purely on the feedback received from the downstream
SIP servers and does not require the SIP load balancer to inspect
an incoming request.

=20

Any solution needs to clearly specify its scope.  A solution also=20
needs to clearly state any limitations, in performance or otherwise,=20
the specified load balancing mechanism may have.  In particular,=20
the solution shall carefully define the deployment considerations for=20
the effective operation of the specified mechanisms and discuss,=20
for example, when a mechanism requires coordinated deployment and=20
operation (if all servers need to deploy the same mechanism, certain=20
configuration values need to be identical on all servers, etc.), when=20
a mechanism can become less effective or ineffective under some =
conditions,=20
or especially if there are cases when a mechanism these considerations=20
is to allow potential deployments to make the best use of these =
mechanism in=20
their particular networks.
=20
SIPLB Working Group will thoroughly identify use cases, provide example=20
design & system architectures and deployment scenarios, and=20
define requirements.
=20
The group will produce:
=20
1) Use case and requirement document.
2) A document surveying SIP load balancing strategies in use today.
3) An architecture document showing sample SIP topologies.
4) Specification for SIP based overload scheme applicable to a=20
   signaling-only SIP server.
5) Specification for SIP based overload scheme applicable to a
   media-based SIP server.
=20
Goals and Milestones
Mar 2012  Survey document for SIP load balancing strategies to IESG
          as an Informational document.
Jun 2012  Use cases and requirement document to IESG as an Informational
          document.
Aug 2012  Design & Architecture to IESG as Informational RFC
Feb 2013  Submit signaling based SIP overload solution to IESG as=20
          Proposed Standard RFC=20
Feb 2013  Submit signaling and media based SIP overload solution to=20
          IESG as Proposed Standard RFC=20


------_=_NextPart_001_01CC24F3.3456C88A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

















 



 












De : =
Parthasarathi R
(partr) [mailto:partr@cisco.com] 

Envoy=E9 : mercredi 25 mai 2011 06:24

=C0 : CHATRAS Bruno RD-CORE-ISS; dispatch@ietf.org

Objet : RE: [dispatch] SIP Load balancing (SIPLB) Charter =
proposal









 



Hi Bruno,



 



Thanks for your interest in the charter. Please =
read
inline.



 



Thanks



Partha



 












From:=
 =
bruno.chatras@orange-ftgroup.com
[mailto:bruno.chatras@orange-ftgroup.com] 

Sent: Tuesday, May 24, 2011 11:00 PM

To: Parthasarathi R (partr); dispatch@ietf.org

Subject: RE: [dispatch] SIP Load balancing (SIPLB) Charter =
proposal



Hi all,



 



1 comment and 1 question



 



Comment: In the list of considerations that must be taken =
into
account I would add =AB Whether the load balancer is SIP-aware or =
not.



 



<Partha> Till now, we are discussing about SIP-aware =
load
balancer only. In case the load balancer is SIP-unaware, is it
something like load-balance by open-loop model wherein there is no
feedback required from downstream servers or load balance in the =
transport
layer instead of SIP layer ?. Could you please explain your =
consideration
in detail. </Partha>



[BC] I was referring to a load =
balancer
at the transport layer with feedback from downstream =
servers.



 



Question: Is the Charter intended to cover architectures =
with an
in-path load balancer in front of a farm of SIP servers only or is it =
expected
to cover as well other architectures where the load balancer is off-path =
or
even architectures where load balancing just relies on frequent updates =
of the
DNS? 



<Partha>  The charter's first
consideration explains open-loop model. So, it might be =
possible to
get the solution through open-loop model (off-path). ISTM, DNS =
update
for load balancer also falls under open-loop model until otherwise DNS =
weight
and priority varies so often based on system load but it is next to =
impossible
to change DNS so frequently in the real-time. =
</Partha>



[BC] I was indeed referring to =
solutions
where the DNS is frequently updated (weight and priority) using RFC =
2136. Note that
there are architectures where the DNS is not directly updated by the SIP
servers but by an intermediate entity (see e.g. the LDF in http://www.3gpp.org/ftp/Specs/archive/23_series/23.812/23812-115.zip=
)



 



 



I guess that 1st consideration will =




 



Bruno



 



 



 



 












De :
dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] De la =
part de
Parthasarathi R (partr)

Envoy=E9 : lundi 23 mai 2011 17:04

=C0 : dispatch@ietf.org

Objet : [dispatch] SIP Load balancing (SIPLB) Charter =
proposal









 



Hi
all,






 









Charter
proposal for SIP load balancing (SIPLB) is written in this mail to =
create
a new WG related to SIP based load balancing.









 









There
are lot of interest in SIP load balancing work during the time of =
IETF-80 and
the side meeting leads to the creation of this charter. There are lot of =
draft
submitted in Dispatch related to this work and the list is as =
follows:









 









[1]http://too=
ls.ietf.org/html/draft-bessis-dispatch-adaptive-load-balancing-00

[2]http://tools.ietf.org/html/draft-jones-sip-overload-sce-00

[3]http://tools.ietf.org/html/draft-partha-dispatch-sip-media-overload-co=
ntrol-00









 









To
make the progress in the work, the charter currently focus on two =
types of
SIP based load balancing namely signaling only SIP load balancing and
Media-related SIP based load balancing. 









 









Please
provide your value inputs and comments in the =
below charter.









 









Thanks=










Vijay/Partha<=
/span>









 









SIP
Load balancing (SIPLB) Charter

----------------------------------

 

Session Load balancing (SIPLB) working group is chartered to define a =


SIP-based protocol for load balancing SIP sessions.

 

Load balancing across a farm of SIP servers can be done today, but =
without 

generally agreed upon principles on how to best do accomplish this.

Confounding the problem is that a SIP farm may consist of hosts with =


varying capabilities, example, a SIP proxy, a back-to-back user agent =


(B2BUA), a public-switched telephone system (PSTN) gateway, SIP Media =


servers etc. The capabilities and processing capacity on hosts in the =
farm 

may be different, sometimes vastly, from each other.  Furthermore, =
the 

duration of time that a SIP host requires to process a SIP request 

may vary. SIP proxies, operating at the transaction layer, may be 

more efficient at processing transactions than a B2BUA would be, 

which may need to maintain a long-lived dialogue state in addition to =


the transaction state.  PSTN gateways may have other limitations =
such 

as media resources that may be depleted even though the gateway may 

have enough processing power (i.e., CPU) to handle incoming =
requests.

 

In face of such diversity, simple load balancing schemes based on 

round-robin selection tend to work only when many assumptions are =
met.

First, the relative capacity and processing resources of all SIP servers =


in the farm should be nearly equal.  Furthermore, because a =
round-robin 

scheme presents a load of (1/n)*N to each server, where n =3D number of =


servers and N =3D arrival rate in requests per second, it assumes that =


the service time at each server is such that the utilization of each =


server is not negatively impacted (i.e., utilization ratio of the =
arrival 

rate over the mean service rate is less than 1.0).  And finally, =


the round-robin load balancing does not have a backward feedback =
mechanism 

whereby the load-balanced server can inform the load balancer of its =


current utilization (i.e., round-robin load balancing acts as an =
open-loop 

controller).

 

The SIP load balancing working group is, therefore, chartered to 

arrive at a load balancing scheme that distributes SIP requests to 

a collection of servers to effectively utilize the resources at those =


servers. These resources can include CPU, memory, network bandwidth, =


input/output, DSP, DS0 or disk resources.  The load balancing

scheme must prevent excessive oscillation in the collection of

servers.









 









In
order to achieve such a load balancing scheme in practice, the following =


considerations must be taken in account:

 

1) Should the load balancing scheme have a closed-loop model, i.e., 

should it report utilization to the load balancer to allow the 

load balancer to distribute requests proportionally?

 

2) What should the diversity of the SIP hosts in a farm be?  Is =


it reasonable to assume that the same load balancing scheme should 

be applicable to a pair of SIP servers, one of which can handle 

an order of magnitude more requests per unit time that the other?

 

3) What information must be provisioned into the load balancer and 

the servers?

 

4) As SIP request resource consumption in SIP signaling only server 

varies drastically from SIP media servers, should the solution be 

split such that load balancing of a pure signaling server is different =


than that of a SIP server that handles signaling as well as media?

 

The last consideration above is especially important since a =
solution

to load balancing a media farm will require a model where the SIP 

load balancer is closely coupled with the downstream SIP servers.

In such a model, the SIP load balancer knows the resources available

at each of the downstream SIP servers and is able to inspect an

incoming request to determine its media-related requirements and =
thus

dispatch it to the downstream SIP server that has the highest

probability of servicing that request.  In some architectures, =
such

a coupling reduces post-dial delay.  









 









Keeping
the SIP load balancer and the downstream SIP servers 

loosely coupled suffices for load balancing to a farm of SIP

servers that only handle signaling.  A loosely coupled model

operates purely on the feedback received from the downstream

SIP servers and does not require the SIP load balancer to inspect

an incoming request.









 









Any
solution needs to clearly specify its scope.  A solution also 

needs to clearly state any limitations, in performance or otherwise, =


the specified load balancing mechanism may have.  In particular, =


the solution shall carefully define the deployment considerations for =


the effective operation of the specified mechanisms and discuss, 

for example, when a mechanism requires coordinated deployment and 

operation (if all servers need to deploy the same mechanism, certain =


configuration values need to be identical on all servers, etc.), when =


a mechanism can become less effective or ineffective under some =
conditions, 

or especially if there are cases when a mechanism these considerations =


is to allow potential deployments to make the best use of these =
mechanism in 

their particular networks.

 

SIPLB Working Group will thoroughly identify use cases, provide example =


design & system architectures and deployment scenarios, and 

define requirements.

 

The group will produce:

 

1) Use case and requirement document.

2) A document surveying SIP load balancing strategies in use today.

3) An architecture document showing sample SIP topologies.

4) Specification for SIP based overload scheme applicable to a 

   signaling-only SIP server.

5) Specification for SIP based overload scheme applicable to a

   media-based SIP server.

 

Goals and Milestones

Mar 2012  Survey document for SIP load balancing strategies to =
IESG

          as an =
Informational
document.

Jun 2012  Use cases and requirement document to IESG as an =
Informational

          document.

Aug 2012  Design & Architecture to IESG as Informational =
RFC

Feb 2013  Submit signaling based SIP overload solution to IESG as =


          Proposed Standard =
RFC 

Feb 2013  Submit signaling and media based SIP overload solution to =


          IESG as Proposed
Standard RFC 


















------_=_NextPart_001_01CC24F3.3456C88A--

From bruno.chatras@orange-ftgroup.com  Tue Jun  7 02:18:47 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F7911E8077 for ; Tue,  7 Jun 2011 02:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.729
X-Spam-Level: 
X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=0.519,  BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKn9UjZvmmvd for ; Tue,  7 Jun 2011 02:18:46 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id B500211E807A for ; Tue,  7 Jun 2011 02:18:45 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 47F966D8010; Tue,  7 Jun 2011 11:20:01 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 33B7C6C8003; Tue,  7 Jun 2011 11:20:01 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 7 Jun 2011 11:18:44 +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_01CC24F3.E5CB59A4"
Date: Tue, 7 Jun 2011 11:18:43 +0200
Message-ID: <9ECCF01B52E7AB408A7EB8535264214102EE6374@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] SIP Load balancing (SIPLB) Charter proposal - overload
Thread-Index: AcwZVtBeNaZm1dRbQuqPlztWqYWALQAA7TCwADcJ4MAAFrdSIAKYbBog
References:  <9ECCF01B52E7AB408A7EB8535264214102E4435E@ftrdmel0.rd.francetelecom.fr> 
From: 
To: , 
X-OriginalArrivalTime: 07 Jun 2011 09:18:44.0563 (UTC) FILETIME=[E641DA30:01CC24F3]
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal - overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jun 2011 09:18:47 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC24F3.E5CB59A4
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Items 4 and 5 are referring to an overload scheme rather than a load =
balancing scheme. Any reason for that? Typo?

=20

Same comment applies to the last two milestones

=20

Bruno

=20

=20

=20

=20

=20

De : dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] De la =
part de Parthasarathi R (partr)
Envoy=E9 : lundi 23 mai 2011 17:04
=C0 : dispatch@ietf.org
Objet : [dispatch] SIP Load balancing (SIPLB) Charter proposal

=20

Hi all,

=20

Charter proposal for SIP load balancing (SIPLB) is written in this mail =
to create a new WG related to SIP based load balancing.

=20

There are lot of interest in SIP load balancing work during the time of =
IETF-80 and the side meeting leads to the creation of this charter. =
There are lot of draft submitted in Dispatch related to this work and =
the list is as follows:

=20

[1]http://tools.ietf.org/html/draft-bessis-dispatch-adaptive-load-balanci=
ng-00
[2]http://tools.ietf.org/html/draft-jones-sip-overload-sce-00
[3]http://tools.ietf.org/html/draft-partha-dispatch-sip-media-overload-co=
ntrol-00

=20

To make the progress in the work, the charter currently focus on two =
types of SIP based load balancing namely signaling only SIP load =
balancing and Media-related SIP based load balancing.=20

=20

Please provide your value inputs and comments in the below charter.

=20

Thanks

Vijay/Partha

=20

SIP Load balancing (SIPLB) Charter
----------------------------------
=20
Session Load balancing (SIPLB) working group is chartered to define a=20
SIP-based protocol for load balancing SIP sessions.
=20
Load balancing across a farm of SIP servers can be done today, but =
without=20
generally agreed upon principles on how to best do accomplish this.
Confounding the problem is that a SIP farm may consist of hosts with=20
varying capabilities, example, a SIP proxy, a back-to-back user agent=20
(B2BUA), a public-switched telephone system (PSTN) gateway, SIP Media=20
servers etc. The capabilities and processing capacity on hosts in the =
farm=20
may be different, sometimes vastly, from each other.  Furthermore, the=20
duration of time that a SIP host requires to process a SIP request=20
may vary. SIP proxies, operating at the transaction layer, may be=20
more efficient at processing transactions than a B2BUA would be,=20
which may need to maintain a long-lived dialogue state in addition to=20
the transaction state.  PSTN gateways may have other limitations such=20
as media resources that may be depleted even though the gateway may=20
have enough processing power (i.e., CPU) to handle incoming requests.
=20
In face of such diversity, simple load balancing schemes based on=20
round-robin selection tend to work only when many assumptions are met.
First, the relative capacity and processing resources of all SIP servers =

in the farm should be nearly equal.  Furthermore, because a round-robin=20
scheme presents a load of (1/n)*N to each server, where n =3D number of=20
servers and N =3D arrival rate in requests per second, it assumes that=20
the service time at each server is such that the utilization of each=20
server is not negatively impacted (i.e., utilization ratio of the =
arrival=20
rate over the mean service rate is less than 1.0).  And finally,=20
the round-robin load balancing does not have a backward feedback =
mechanism=20
whereby the load-balanced server can inform the load balancer of its=20
current utilization (i.e., round-robin load balancing acts as an =
open-loop=20
controller).
=20
The SIP load balancing working group is, therefore, chartered to=20
arrive at a load balancing scheme that distributes SIP requests to=20
a collection of servers to effectively utilize the resources at those=20
servers. These resources can include CPU, memory, network bandwidth,=20
input/output, DSP, DS0 or disk resources.  The load balancing
scheme must prevent excessive oscillation in the collection of
servers.

=20

In order to achieve such a load balancing scheme in practice, the =
following=20
considerations must be taken in account:
=20
1) Should the load balancing scheme have a closed-loop model, i.e.,=20
should it report utilization to the load balancer to allow the=20
load balancer to distribute requests proportionally?
=20
2) What should the diversity of the SIP hosts in a farm be?  Is=20
it reasonable to assume that the same load balancing scheme should=20
be applicable to a pair of SIP servers, one of which can handle=20
an order of magnitude more requests per unit time that the other?
=20
3) What information must be provisioned into the load balancer and=20
the servers?
=20
4) As SIP request resource consumption in SIP signaling only server=20
varies drastically from SIP media servers, should the solution be=20
split such that load balancing of a pure signaling server is different=20
than that of a SIP server that handles signaling as well as media?
=20
The last consideration above is especially important since a solution
to load balancing a media farm will require a model where the SIP=20
load balancer is closely coupled with the downstream SIP servers.
In such a model, the SIP load balancer knows the resources available
at each of the downstream SIP servers and is able to inspect an
incoming request to determine its media-related requirements and thus
dispatch it to the downstream SIP server that has the highest
probability of servicing that request.  In some architectures, such
a coupling reduces post-dial delay. =20

=20

Keeping the SIP load balancer and the downstream SIP servers=20
loosely coupled suffices for load balancing to a farm of SIP
servers that only handle signaling.  A loosely coupled model
operates purely on the feedback received from the downstream
SIP servers and does not require the SIP load balancer to inspect
an incoming request.

=20

Any solution needs to clearly specify its scope.  A solution also=20
needs to clearly state any limitations, in performance or otherwise,=20
the specified load balancing mechanism may have.  In particular,=20
the solution shall carefully define the deployment considerations for=20
the effective operation of the specified mechanisms and discuss,=20
for example, when a mechanism requires coordinated deployment and=20
operation (if all servers need to deploy the same mechanism, certain=20
configuration values need to be identical on all servers, etc.), when=20
a mechanism can become less effective or ineffective under some =
conditions,=20
or especially if there are cases when a mechanism these considerations=20
is to allow potential deployments to make the best use of these =
mechanism in=20
their particular networks.
=20
SIPLB Working Group will thoroughly identify use cases, provide example=20
design & system architectures and deployment scenarios, and=20
define requirements.
=20
The group will produce:
=20
1) Use case and requirement document.
2) A document surveying SIP load balancing strategies in use today.
3) An architecture document showing sample SIP topologies.
4) Specification for SIP based overload scheme applicable to a=20
   signaling-only SIP server.
5) Specification for SIP based overload scheme applicable to a
   media-based SIP server.
=20
Goals and Milestones
Mar 2012  Survey document for SIP load balancing strategies to IESG
          as an Informational document.
Jun 2012  Use cases and requirement document to IESG as an Informational
          document.
Aug 2012  Design & Architecture to IESG as Informational RFC
Feb 2013  Submit signaling based SIP overload solution to IESG as=20
          Proposed Standard RFC=20
Feb 2013  Submit signaling and media based SIP overload solution to=20
          IESG as Proposed Standard RFC=20


------_=_NextPart_001_01CC24F3.E5CB59A4
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

















Items 4 and 5 are referring to an overload =
scheme rather
than a load balancing scheme. Any reason for that? =
Typo?



 



Same
comment applies to the last two milestones



 



Bruno<=
span
lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>



 






 



 



 



 












De :
dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] De la =
part de
Parthasarathi R (partr)

Envoy=E9 : lundi 23 mai 2011 17:04

=C0 : dispatch@ietf.org

Objet : [dispatch] SIP Load balancing (SIPLB) Charter =
proposal









 



Hi
all,






 









Charter
proposal for SIP load balancing (SIPLB) is written in this mail to =
create
a new WG related to SIP based load balancing.









 









There
are lot of interest in SIP load balancing work during the time of =
IETF-80 and
the side meeting leads to the creation of this charter. There are lot of =
draft
submitted in Dispatch related to this work and the list is as =
follows:









 









[1]http://too=
ls.ietf.org/html/draft-bessis-dispatch-adaptive-load-balancing-00

[2]http://tools.ietf.org/html/draft-jones-sip-overload-sce-00

[3]http://tools.ietf.org/html/draft-partha-dispatch-sip-media-overload-co=
ntrol-00









 









To
make the progress in the work, the charter currently focus on two =
types of
SIP based load balancing namely signaling only SIP load balancing and
Media-related SIP based load balancing. 









 









Please
provide your value inputs and comments in the =
below charter.









 









Thanks=










Vijay/Partha<=
/span>









 









SIP
Load balancing (SIPLB) Charter

----------------------------------

 

Session Load balancing (SIPLB) working group is chartered to define a =


SIP-based protocol for load balancing SIP sessions.

 

Load balancing across a farm of SIP servers can be done today, but =
without 

generally agreed upon principles on how to best do accomplish this.

Confounding the problem is that a SIP farm may consist of hosts with =


varying capabilities, example, a SIP proxy, a back-to-back user agent =


(B2BUA), a public-switched telephone system (PSTN) gateway, SIP Media =


servers etc. The capabilities and processing capacity on hosts in the =
farm 

may be different, sometimes vastly, from each other.  Furthermore, =
the 

duration of time that a SIP host requires to process a SIP request 

may vary. SIP proxies, operating at the transaction layer, may be 

more efficient at processing transactions than a B2BUA would be, 

which may need to maintain a long-lived dialogue state in addition to =


the transaction state.  PSTN gateways may have other limitations =
such 

as media resources that may be depleted even though the gateway may 

have enough processing power (i.e., CPU) to handle incoming =
requests.

 

In face of such diversity, simple load balancing schemes based on 

round-robin selection tend to work only when many assumptions are =
met.

First, the relative capacity and processing resources of all SIP servers =


in the farm should be nearly equal.  Furthermore, because a =
round-robin 

scheme presents a load of (1/n)*N to each server, where n =3D number of =


servers and N =3D arrival rate in requests per second, it assumes that =


the service time at each server is such that the utilization of each =


server is not negatively impacted (i.e., utilization ratio of the =
arrival 

rate over the mean service rate is less than 1.0).  And finally, =


the round-robin load balancing does not have a backward feedback =
mechanism 

whereby the load-balanced server can inform the load balancer of its =


current utilization (i.e., round-robin load balancing acts as an =
open-loop 

controller).

 

The SIP load balancing working group is, therefore, chartered to 

arrive at a load balancing scheme that distributes SIP requests to 

a collection of servers to effectively utilize the resources at those =


servers. These resources can include CPU, memory, network bandwidth, =


input/output, DSP, DS0 or disk resources.  The load balancing

scheme must prevent excessive oscillation in the collection of

servers.









 









In
order to achieve such a load balancing scheme in practice, the following =


considerations must be taken in account:

 

1) Should the load balancing scheme have a closed-loop model, i.e., 

should it report utilization to the load balancer to allow the 

load balancer to distribute requests proportionally?

 

2) What should the diversity of the SIP hosts in a farm be?  Is =


it reasonable to assume that the same load balancing scheme should 

be applicable to a pair of SIP servers, one of which can handle 

an order of magnitude more requests per unit time that the other?

 

3) What information must be provisioned into the load balancer and 

the servers?

 

4) As SIP request resource consumption in SIP signaling only server 

varies drastically from SIP media servers, should the solution be 

split such that load balancing of a pure signaling server is different =


than that of a SIP server that handles signaling as well as media?

 

The last consideration above is especially important since a =
solution

to load balancing a media farm will require a model where the SIP 

load balancer is closely coupled with the downstream SIP servers.

In such a model, the SIP load balancer knows the resources available

at each of the downstream SIP servers and is able to inspect an

incoming request to determine its media-related requirements and =
thus

dispatch it to the downstream SIP server that has the highest

probability of servicing that request.  In some architectures, =
such

a coupling reduces post-dial delay.  









 









Keeping
the SIP load balancer and the downstream SIP servers 

loosely coupled suffices for load balancing to a farm of SIP

servers that only handle signaling.  A loosely coupled model

operates purely on the feedback received from the downstream

SIP servers and does not require the SIP load balancer to inspect

an incoming request.









 









Any
solution needs to clearly specify its scope.  A solution also 

needs to clearly state any limitations, in performance or otherwise, =


the specified load balancing mechanism may have.  In particular, =


the solution shall carefully define the deployment considerations for =


the effective operation of the specified mechanisms and discuss, 

for example, when a mechanism requires coordinated deployment and 

operation (if all servers need to deploy the same mechanism, certain =


configuration values need to be identical on all servers, etc.), when =


a mechanism can become less effective or ineffective under some =
conditions, 

or especially if there are cases when a mechanism these considerations =


is to allow potential deployments to make the best use of these =
mechanism in 

their particular networks.

 

SIPLB Working Group will thoroughly identify use cases, provide example =


design & system architectures and deployment scenarios, and 

define requirements.

 

The group will produce:

 

1) Use case and requirement document.

2) A document surveying SIP load balancing strategies in use today.

3) An architecture document showing sample SIP topologies.

4) Specification for SIP based overload scheme applicable to a 

   signaling-only SIP server.

5) Specification for SIP based overload scheme applicable to a

   media-based SIP server.

 

Goals and Milestones

Mar 2012  Survey document for SIP load balancing strategies to =
IESG

          as an =
Informational document.

Jun 2012  Use cases and requirement document to IESG as an =
Informational

          document.

Aug 2012  Design & Architecture to IESG as Informational =
RFC

Feb 2013  Submit signaling based SIP overload solution to IESG as =


          Proposed Standard =
RFC 

Feb 2013  Submit signaling and media based SIP overload solution to =


          IESG as Proposed
Standard RFC 


















------_=_NextPart_001_01CC24F3.E5CB59A4--

From xavier.marjou@gmail.com  Tue Jun  7 02:28:15 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3209311E80BF for ; Tue,  7 Jun 2011 02:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2FQwhMbxxiT for ; Tue,  7 Jun 2011 02:28:14 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E3FD211E8095 for ; Tue,  7 Jun 2011 02:28:13 -0700 (PDT)
Received: by vxg33 with SMTP id 33so4330526vxg.31 for ; Tue, 07 Jun 2011 02:28:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=hklkzskUAPDAosm9IWsaqa/GzxLgqkENi5STSlAQWYU=; b=t9LxtT05NjBZFmFe+9RVSaAY7UcyLgAmMPGN1l5SeYfSFpoZktBJ0oVtA3Ykna38Tg ahHErJbmUZxpnI35oelwhVAxKzpsXar3sCkn8wuSNx9asSV5jjdYtwedB1irQqUjEuQV qWr+HoScmBMekiGK4FuRt3+ymhAeiO43A2F/0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=BgWyTI9Q0XyS2wk4skPPPZ/VU6j+y3qTvAlkNipZVDNyaBhar2FOx1/HiteVZOT7fX Tv17I/vvYfHb/ul/TSIT3+f5b+DvQrxr9gQ/IJXcPMCPTWMZG8Z7TG8MuqDpK+0nm2ul 9ArC8dW7zj6WOKiza/8+u7eKv4WWqL/SllpFU=
MIME-Version: 1.0
Received: by 10.52.112.106 with SMTP id ip10mr16208vdb.127.1307438893320; Tue, 07 Jun 2011 02:28:13 -0700 (PDT)
Sender: xavier.marjou@gmail.com
Received: by 10.220.159.132 with HTTP; Tue, 7 Jun 2011 02:28:13 -0700 (PDT)
In-Reply-To: <006501cc2464$5e4f5a10$1aee0e30$@us>
References: <4DDA0388.60702@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A415@ESESSCMS0356.eemea.ericsson.se> <006501cc2464$5e4f5a10$1aee0e30$@us>
Date: Tue, 7 Jun 2011 11:28:13 +0200
X-Google-Sender-Auth: ZwP_MXmnY3xs_J3Cb5jJLJQPPSs
Message-ID: 
From: Xavier Marjou 
To: DISPATCH list 
Content-Type: multipart/alternative; boundary=bcaec548a1cfcd4abc04a51bd68f
Subject: Re: [dispatch] charter proposal: SIP end-to-end Session Identifier
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jun 2011 09:28:15 -0000

--bcaec548a1cfcd4abc04a51bd68f
Content-Type: text/plain; charset=ISO-8859-1

+1

On Mon, Jun 6, 2011 at 6:11 PM, Richard Shockey  wrote:

> Long Long overdue ..  +1
>
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf
> Of Christer Holmberg
> Sent: Monday, June 06, 2011 10:49 AM
> To: Salvatore Loreto; dispatch@ietf.org
> Subject: Re: [dispatch] charter proposal: SIP end-to-end Session Identifier
>
> Hi,
>
> I support the charter proposal. I think this is an important feature.
>
> Regards,
>
> Christer
>
> ________________________________
> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of
> Salvatore Loreto [salvatore.loreto@ericsson.com]
> Sent: Monday, May 23, 2011 9:49 AM
> To: dispatch@ietf.org
> Subject: [dispatch] charter proposal: SIP end-to-end Session Identifier
>
> Hi there,
> below a charter proposal for a new wg working on End-to-end Session
> Identifier in SIP.
>
> In an effort to make progress and to facilitate the discussion
> we have also created an Internet Draft that captures, at a high level,
> the requirements and use cases.
> (It was submitted by Paul E. Jones last Friday; here the link:
> http://www.ietf.org/id/draft-jones-ipmc-session-id-reqts-00.txt )
>
> cheers
> /Sal
> End-to-end Session Identifier in SIP (charter proposal )
> ----------------------------------------------
>
> The end-to-end Session Identifier in an SIP-based multimedia communication
> refers to the ability
> for endpoints, intermediate devices, and management and monitoring system
> to
> identify
> and correlate SIP messages and dialogs of the same higher-level end-to-end
> "communication
> session" across multiple SIP devices and hops.
>
> Unfortunately, there are a number of factors that contribute to the fact
> that the current
> dialog identifiers as defined in SIP is not suitable for end-to-end session
> identification.
> Perhaps the most important factor worth describing is that in real-world
> deployments devices like Session Border Controllers (SBC) often change the
> current call
> identifiers (e.g., the From-tag and To-tag that are used in conjunction
> with
> the Call-ID header
> to make the dialog-id) as the session signaling passes through.
>
>
> An end-to-end Session Identifier should allow the possibility to identify
> the communication session
> from the point of origin, passing through any number of intermediaries, to
> the ultimate point
> of termination. It should have the same aim as the From-tag, To-tag and
> Call-ID conjunction,
> but should not be mangled by intermediaries.
>
> A SIP end-to-end Session Identifier has been considered as possible
> solution
> of different use cases like
> troubleshooting, billing, session tracking, session recording, media and
> signaling correlation, and so forth.
> Some of these requirements have also been identified and come directly from
> other existing
> working group within the RAI area (e.g. SIPRec, Splices).
>
> Moreover, other SDOs have identified the need for SIP and H.323 to carry
> the
> same "session ID" value(s)
> so that it is possible identify a call end-to end even when performing
> inter
> working between
> protocols.
>
>
> This group will first focus on a document that will identify, collect and
> discuss all the
> requirements and the use cases that have been identified.
> The document may identify the possibility to design a general mechanism or
> the need
> to design multiple purpose built identifiers.
> Once the needs are clear and identified, the working group will specify the
> mechanism(s).
>
>
> Specifically, the proposed working group will develop the following
> deliverable:
>
>  1.  A requirement and use case document with key consideration for SIP
> Session
> End-to-End identifier. The document will discuss the possibility of
> designing
> a general mechanism or the needs to design multiple purpose build
> identifier.
>  2.  Specification of new mechanism(s).
>
> Goal and Milestone:
>    October 2011 - Requirement and use case document sent to the IESG
> (Information)
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

--bcaec548a1cfcd4abc04a51bd68f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1

On Mon, Jun 6, 2011 at 6:11 PM, Richar=
d Shockey <richa=
rd@shockey.us> wrote:

Long Long overdue .. =A0+1



-----Original Message-----

From: dispatch-bounces@ietf.or=
g [mailto:dispatch-bounces=
@ietf.org] On Behalf

Of Christer Holmberg

Sent: Monday, June 06, 2011 10:49 AM

To: Salvatore Loreto; dispatch@ietf.or=
g

Subject: Re: [dispatch] charter proposal: SIP end-to-end Session Identifier=





Hi,



I support the charter proposal. I think this is an important feature.



Regards,



Christer



________________________________

From: dispatch-bounces@ietf.or=
g [dispatch-bounces@ietf.o=
rg] On Behalf Of

Salvatore Loreto [salvator=
e.loreto@ericsson.com]

Sent: Monday, May 23, 2011 9:49 AM

To: dispatch@ietf.org

Subject: [dispatch] charter proposal: SIP end-to-end Session Identifier



Hi there,

below a charter proposal for a new wg working on End-to-end Session

Identifier in SIP.



In an effort to make progress and to facilitate the discussion

we have also created an Internet Draft that captures, at a high level,

the requirements and use cases.

(It was submitted by Paul E. Jones last Friday; here the link:

http://www.ietf.org/id/draft-jones-ipmc-session-id-reqts=
-00.txt )



cheers

/Sal

End-to-end Session Identifier in SIP (charter proposal )

----------------------------------------------



The end-to-end Session Identifier in an SIP-based multimedia communication<=
br>
refers to the ability

for endpoints, intermediate devices, and management and monitoring system t=
o

identify

and correlate SIP messages and dialogs of the same higher-level end-to-end<=
br>
"communication

session" across multiple SIP devices and hops.



Unfortunately, there are a number of factors that contribute to the fact
that the current

dialog identifiers as defined in SIP is not suitable for end-to-end session=


identification.

Perhaps the most important factor worth describing is that in real-world
deployments devices like Session Border Controllers (SBC) often change the<=
br>
current call

identifiers (e.g., the From-tag and To-tag that are used in conjunction wit=
h

the Call-ID header

to make the dialog-id) as the session signaling passes through.





An end-to-end Session Identifier should allow the possibility to identify
the communication session

from the point of origin, passing through any number of intermediaries, to<=
br>
the ultimate point

of termination. It should have the same aim as the From-tag, To-tag and

Call-ID conjunction,

but should not be mangled by intermediaries.



A SIP end-to-end Session Identifier has been considered as possible solutio=
n

of different use cases like

troubleshooting, billing, session tracking, session recording, media and
signaling correlation, and so forth.

Some of these requirements have also been identified and come directly from=


other existing

working group within the RAI area (e.g. SIPRec, Splices).



Moreover, other SDOs have identified the need for SIP and H.323 to carry th=
e

same "session ID" value(s)

so that it is possible identify a call end-to end even when performing inte=
r

working between

protocols.





This group will first focus on a document that will identify, collect and
discuss all the

requirements and the use cases that have been identified.

The document may identify the possibility to design a general mechanism or<=
br>
the need

to design multiple purpose built identifiers.

Once the needs are clear and identified, the working group will specify the=


mechanism(s).





Specifically, the proposed working group will develop the following

deliverable:



=A01. =A0A requirement and use case document with key consideration for SIP=


Session

End-to-End identifier. The document will discuss the possibility of

designing

a general mechanism or the needs to design multiple purpose build

identifier.

=A02. =A0Specification of new mechanism(s).



Goal and Milestone:

 =A0 =A0October 2011 - Requirement and use case document sent to the IESG
(Information)



_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch



_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch





--bcaec548a1cfcd4abc04a51bd68f--

From christer.holmberg@ericsson.com  Tue Jun  7 02:37:26 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A5521F8497 for ; Tue,  7 Jun 2011 02:37:26 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RK5nBo8YWlV for ; Tue,  7 Jun 2011 02:37:25 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCA821F848B for ; Tue,  7 Jun 2011 02:37:24 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c17ae00000262e-17-4dedf1530707
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AB.4F.09774.351FDED4; Tue,  7 Jun 2011 11:37:23 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 7 Jun 2011 11:37:19 +0200
From: Christer Holmberg 
To: "marianne.mohali@orange-ftgroup.com" ,  "dispatch@ietf.org" , "fluffy@cisco.com" , "mary.ietf.barnes@gmail.com" 
Date: Tue, 7 Jun 2011 11:37:18 +0200
Thread-Topic: [dispatch] charter proposal for draft-mohali-dispatch-reason-for-applications
Thread-Index: AcwaMdSnr4VEDUaRSiW1XMALaAd9RQAAJjvgAADu+rACr/7/EA==
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3237C5@ESESSCMS0356.eemea.ericsson.se>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [dispatch] charter proposal for draft-mohali-dispatch-reason-for-applications
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jun 2011 09:37:26 -0000

Hi,

Eventhough I have some minor issues with the proposed solution, I DO think =
there is a need to solve the problem indicated in the proposed Problem Stat=
ement, and I support to start working on this.

Regards,

Christer


> -----Original Message-----
> From: dispatch-bounces@ietf.org=20
> [mailto:dispatch-bounces@ietf.org] On Behalf Of=20
> marianne.mohali@orange-ftgroup.com
> Sent: 24. toukokuuta 2011 20:23
> To: dispatch@ietf.org; fluffy@cisco.com; mary.ietf.barnes@gmail.com
> Subject: [dispatch] charter proposal for=20
> draft-mohali-dispatch-reason-for-applications
>=20
> Hi,
>=20
> I am not proposing a new working group but trying to find the=20
> good place to solve the following problem.
>=20
> Problem Statment
> ----------------
>=20
> Decisions made by one application about how to handle a=20
> session often depend on which other types of applications are=20
> involved in this session. Hence, in the context of SIP, when=20
> several remote applications are involved in the processing of=20
> one session, there is a need for a mechanism enabling one=20
> application to explicitly identify itself when issuing or=20
> re-targeting a request or response. This will enable=20
> applications receiving this information to take appropriate=20
> decisions on how to further process the session.
>=20
>    1.  Need to convey the identity of the application having=20
> "acted" on the call, in order to allow a downstream=20
> application to avoid undesirable service interactions (e.g.=20
> by deciding whether to execute a particular feature depending=20
> on the call history).
>    2.  Need to convey the identity of the application having=20
> caused a specific number translation and allow the transfer=20
> target to easily find out the original number that this=20
> application had received, even in case multiple successive=20
> number translations occured.
>    3.  Need to convey the identity of the application having=20
> released the call towards an upstream application that can=20
> take specific decisions.
>=20
> The draft is available at
> http://tools.ietf.org/html/draft-mohali-dispatch-reason-for-ap
plications
> -00
>=20
>=20
> Charter proposal
> ----------------
> The Reason header field [RFC3326] provides a mechanism to=20
> signal the reason why a SIP request or response was issued or=20
> why an initial request was retargeted.
> I-D draft-mohali-dispatch-reason-for-applications proposes to extend
> RFC3326 registering a new protocol value "Application" for=20
> the Reason Header field and a for registering application=20
> types (cause values). The extension process is similar to=20
> RFC4411 that also extend the Reason header.
> This protocol value can be used anywhere the presence of a=20
> Reason Header field is allowed.
> For each new registered value, it has to be defined the following:
> - Cause value:  this is an identifier number corresponding to=20
> the cause value of the protocol-cause parameter in the Reason=20
> header field.
> - Reason text:  this is a unique string identifying the=20
> application name. The reason text is intended to give a short=20
> textual description of the application.
> - Description:  this is a description of the application and=20
> the conditions under which this reason-value is used.=20
> =20
> The work consist in extending RFC3326 (Reason header) for=20
> applications needs.
>=20
>=20
> Goals and Milestones
> --------------------
>=20
> July 2011 Update to draft-mohali-dispatch-reason-for-applications
> addressing concerns raised in the mailing list
>=20
> July 2011 Present update to
> draft-mohali-dispatch-reason-for-applications at IETF 81
>=20
> Nov 2011 Present update to=20
> draft-mohali-dispatch-reason-for-applications
> at IETF 82
>=20
> Mar 2012 Submit draft-mohali-dispatch-reason-for-applications=20
> to IESG as Proposed Standard RFC
> =20
>=20
> Best Regards,
> Marianne
> =20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> =

From R.Jesske@telekom.de  Tue Jun  7 02:51:20 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445DA228004 for ; Tue,  7 Jun 2011 02:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OICReeUH1rOP for ; Tue,  7 Jun 2011 02:51:19 -0700 (PDT)
Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id A4AF9228003 for ; Tue,  7 Jun 2011 02:51:18 -0700 (PDT)
Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 07 Jun 2011 11:49:52 +0200
Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.233]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 7 Jun 2011 11:49:49 +0200
From: 
To: , , , , 
Date: Tue, 7 Jun 2011 11:49:48 +0200
Thread-Topic: [dispatch] charter proposal for draft-mohali-dispatch-reason-for-applications
Thread-Index: AcwaMdSnr4VEDUaRSiW1XMALaAd9RQAAJjvgAADu+rACr/7/EAAAg3Jg
Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D088DCC1B0D@HE111648.emea1.cds.t-internal.com>
References:  <7F2072F1E0DE894DA4B517B93C6A0585194E3237C5@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3237C5@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dispatch] charter proposal for draft-mohali-dispatch-reason-for-applications
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jun 2011 09:51:20 -0000

+1

Mit freundlichen Gr=FC=DFen
Roland Jesske


Deutsche Telekom Netzproduktion GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske
Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt
+49 6151 58 12766 (Tel.)
+49 391 580 133 831 (Fax)
+49 171 8618-445  (Mobil)
E-Mail: mailto:r.jesske@telekom.de
http://www.telekom.de

Erleben, was verbindet.

Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)
Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe=
is, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft Bonn
USt-IdNr. DE 814645262

Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede=
 E-Mail drucken.


> -----Urspr=FCngliche Nachricht-----
> Von: dispatch-bounces@ietf.org
> [mailto:dispatch-bounces@ietf.org] Im Auftrag von Christer Holmberg
> Gesendet: Dienstag, 7. Juni 2011 11:37
> An: marianne.mohali@orange-ftgroup.com; dispatch@ietf.org;
> fluffy@cisco.com; mary.ietf.barnes@gmail.com
> Betreff: Re: [dispatch] charter proposal for
> draft-mohali-dispatch-reason-for-applications
>
>
> Hi,
>
> Eventhough I have some minor issues with the proposed
> solution, I DO think there is a need to solve the problem
> indicated in the proposed Problem Statement, and I support to
> start working on this.
>
> Regards,
>
> Christer
>
>
> > -----Original Message-----
> > From: dispatch-bounces@ietf.org
> > [mailto:dispatch-bounces@ietf.org] On Behalf Of
> > marianne.mohali@orange-ftgroup.com
> > Sent: 24. toukokuuta 2011 20:23
> > To: dispatch@ietf.org; fluffy@cisco.com; mary.ietf.barnes@gmail.com
> > Subject: [dispatch] charter proposal for
> > draft-mohali-dispatch-reason-for-applications
> >
> > Hi,
> >
> > I am not proposing a new working group but trying to find the
> > good place to solve the following problem.
> >
> > Problem Statment
> > ----------------
> >
> > Decisions made by one application about how to handle a
> > session often depend on which other types of applications are
> > involved in this session. Hence, in the context of SIP, when
> > several remote applications are involved in the processing of
> > one session, there is a need for a mechanism enabling one
> > application to explicitly identify itself when issuing or
> > re-targeting a request or response. This will enable
> > applications receiving this information to take appropriate
> > decisions on how to further process the session.
> >
> >    1.  Need to convey the identity of the application having
> > "acted" on the call, in order to allow a downstream
> > application to avoid undesirable service interactions (e.g.
> > by deciding whether to execute a particular feature depending
> > on the call history).
> >    2.  Need to convey the identity of the application having
> > caused a specific number translation and allow the transfer
> > target to easily find out the original number that this
> > application had received, even in case multiple successive
> > number translations occured.
> >    3.  Need to convey the identity of the application having
> > released the call towards an upstream application that can
> > take specific decisions.
> >
> > The draft is available at
> > http://tools.ietf.org/html/draft-mohali-dispatch-reason-for-ap
> plications
> > -00
> >
> >
> > Charter proposal
> > ----------------
> > The Reason header field [RFC3326] provides a mechanism to
> > signal the reason why a SIP request or response was issued or
> > why an initial request was retargeted.
> > I-D draft-mohali-dispatch-reason-for-applications proposes to extend
> > RFC3326 registering a new protocol value "Application" for
> > the Reason Header field and a for registering application
> > types (cause values). The extension process is similar to
> > RFC4411 that also extend the Reason header.
> > This protocol value can be used anywhere the presence of a
> > Reason Header field is allowed.
> > For each new registered value, it has to be defined the following:
> > - Cause value:  this is an identifier number corresponding to
> > the cause value of the protocol-cause parameter in the Reason
> > header field.
> > - Reason text:  this is a unique string identifying the
> > application name. The reason text is intended to give a short
> > textual description of the application.
> > - Description:  this is a description of the application and
> > the conditions under which this reason-value is used.
> >
> > The work consist in extending RFC3326 (Reason header) for
> > applications needs.
> >
> >
> > Goals and Milestones
> > --------------------
> >
> > July 2011 Update to draft-mohali-dispatch-reason-for-applications
> > addressing concerns raised in the mailing list
> >
> > July 2011 Present update to
> > draft-mohali-dispatch-reason-for-applications at IETF 81
> >
> > Nov 2011 Present update to
> > draft-mohali-dispatch-reason-for-applications
> > at IETF 82
> >
> > Mar 2012 Submit draft-mohali-dispatch-reason-for-applications
> > to IESG as Proposed Standard RFC
> >
> >
> > Best Regards,
> > Marianne
> >
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> >
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

From keith.drage@alcatel-lucent.com  Tue Jun  7 03:35:24 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D90B11E80CA for ; Tue,  7 Jun 2011 03:35:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3qTBpIDv6vG for ; Tue,  7 Jun 2011 03:35:23 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4042C11E80F0 for ; Tue,  7 Jun 2011 03:35:23 -0700 (PDT)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p57AZA3O010444 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 Jun 2011 12:35:10 +0200
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 7 Jun 2011 12:35:10 +0200
From: "DRAGE, Keith (Keith)" 
To: Jong Yul Kim , "dispatch@ietf.org" 
Date: Tue, 7 Jun 2011 12:35:09 +0200
Thread-Topic: [dispatch] Emergency Text Messaging using SIP MESSAGE
Thread-Index: Acwe4ryIcmKwFzkUQs2EXsDRnxSA6QGGr+nQ
Message-ID: 
References: <30E0133A-9869-41B1-BCB2-B32E369D7ABB@cs.columbia.edu>
In-Reply-To: <30E0133A-9869-41B1-BCB2-B32E369D7ABB@cs.columbia.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80
Subject: Re: [dispatch] Emergency Text Messaging using SIP MESSAGE
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jun 2011 10:35:24 -0000

1)	I think you need to spend more time arguing the use case for this. I agr=
ee that some PSAPs seem to be currently using SMS but they are doing this w=
ith very limiting restrictions - only for deaf users, the limitations of SM=
S itself, etc. 3GPP themselves do not define SMS for this use. 3GPP are loo=
king at adding message like data, but they are adding this in conjunction w=
ith some other existing conversational mode media. Support of the hard of h=
earing is specified using real time text, with a defined mechanism of inter=
working with PSAPs supported in the PS domain. I see noone arguing for SMS =
usage in 3GPP or page mode messaging by itself.

2)	I think we need to understand better the compatibility issues with what =
you propose. How does the solution you propose avoid having to upgrade ever=
y proxy / SBC along the path in order to have successful conversational typ=
e communication? How does it interact with something like outbound, where m=
ultiple outbound proxies exist? Does interworking with SMS require the upgr=
ade of all SMS systems in the same manner?=20

Regards

Keith

> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Jong Yul Kim
> Sent: 30 May 2011 13:54
> To: dispatch@ietf.org
> Subject: [dispatch] Emergency Text Messaging using SIP MESSAGE
>=20
> Hi everyone,
>=20
> This draft presents mechanisms to allow page-mode text messaging in
> emergency situations.
>=20
> An example of page-mode messaging is when a person sends SMS to an
> emergency number to get help. In this case, there needs to be a way for
> the SMS message to reach the same call taker until the "conversation"
> ends.
>=20
> As emergency call centers are transitioning to a SIP-based solution, the
> draft outlines a mechanism based on SIP MESSAGE method to deliver page-
> mode messages consistently to a call taker.
>=20
> http://tools.ietf.org/html/draft-kim-dispatch-text-01
>=20
> Comments on the draft or which WG it should go to are much appreciated.
> Please let us know your thoughts.
>=20
> Best regards,
>=20
> Jong Yul
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From vkg@bell-labs.com  Tue Jun  7 07:15:19 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5845411E8119 for ; Tue,  7 Jun 2011 07:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4buerHrRlZz for ; Tue,  7 Jun 2011 07:15:18 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3FE11E8116 for ; Tue,  7 Jun 2011 07:15:17 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p57EF783002162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Jun 2011 09:15:08 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p57EF6tL020458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Jun 2011 09:15:06 -0500
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p57EF5Zr025618; Tue, 7 Jun 2011 09:15:06 -0500 (CDT)
Message-ID: <4DEE3280.4040102@bell-labs.com>
Date: Tue, 07 Jun 2011 09:15:28 -0500
From: "Vijay K. Gurbani" 
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: bruno.chatras@orange-ftgroup.com
References: 	<9ECCF01B52E7AB408A7EB8535264214102E4435E@ftrdmel0.rd.francetelecom.fr>	 <9ECCF01B52E7AB408A7EB8535264214102EE6374@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102EE6374@ftrdmel0.rd.francetelecom.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal -	overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jun 2011 14:15:19 -0000

Bruno: Thank you for your feedback.  More inline.

On 06/07/2011 04:18 AM, bruno.chatras@orange-ftgroup.com wrote:
> Items 4 and 5 are referring to an overload scheme rather than a load
> balancing scheme. Any reason for that? Typo?

Item 4 ("As SIP request ... as well as media?") refers to load
balancing.  I cannot find item 5 (if you are referring to
the list of considerations, there are four items there. If
you are referring to something else, please let me know what
it is).

> Same comment applies to the last two milestones

Ooops, this is embarrassing; sorry.  Indeed, the last two milestones
relate to load balancing and should say the following:

Feb 2013  Submit signaling based SIP load balancing solution to IESG as
           Proposed Standard RFC
Feb 2013  Submit signaling and media based SIP load balancing solution
           to IESG as Proposed Standard RFC

Thank you.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/

From md3135@att.com  Tue Jun  7 07:15:49 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1214F11E8112 for ; Tue,  7 Jun 2011 07:15:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.299
X-Spam-Level: 
X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7U1+bV5adlT for ; Tue,  7 Jun 2011 07:15:48 -0700 (PDT)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 25FB011E80F0 for ; Tue,  7 Jun 2011 07:15:48 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: md3135@att.com
X-Msg-Ref: server-3.tower-119.messagelabs.com!1307456146!22893177!1
X-StarScan-Version: 6.2.17; banners=-,-,-
X-Originating-IP: [144.160.20.146]
Received: (qmail 1947 invoked from network); 7 Jun 2011 14:15:47 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jun 2011 14:15:47 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57EEeg1012796; Tue, 7 Jun 2011 10:14:40 -0400
Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57EEYds012643; Tue, 7 Jun 2011 10:14:34 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 7 Jun 2011 10:15:39 -0400
Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA0A395EE1@gaalpa1msgusr7e.ugd.att.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] Emergency Text Messaging using SIP MESSAGE
Thread-Index: Acwe4ryIcmKwFzkUQs2EXsDRnxSA6QGGr+nQAAfYt9A=
References: <30E0133A-9869-41B1-BCB2-B32E369D7ABB@cs.columbia.edu> 
From: "DOLLY, MARTIN C (ATTSI)" 
To: "DRAGE, Keith (Keith)" , "Jong Yul Kim" , 
Cc: "DALY, BRIAN K \(ATTSI\)" 
Subject: Re: [dispatch] Emergency Text Messaging using SIP MESSAGE
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jun 2011 14:15:49 -0000

Greetings,

To add to Keith's points, there is a 4G America white paper and a FCC
CSRIC 4B report that recommends/disallows emergency SMS, as SMS is not
real-time communications and there is no conversation (e.g.,
acknowledgement, response).

Regards,

Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T Services, Inc.
md3135@att.com
+1-609-903-3360




-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of DRAGE, Keith (Keith)
Sent: Tuesday, June 07, 2011 6:35 AM
To: Jong Yul Kim; dispatch@ietf.org
Subject: Re: [dispatch] Emergency Text Messaging using SIP MESSAGE

1)	I think you need to spend more time arguing the use case for
this. I agree that some PSAPs seem to be currently using SMS but they
are doing this with very limiting restrictions - only for deaf users,
the limitations of SMS itself, etc. 3GPP themselves do not define SMS
for this use. 3GPP are looking at adding message like data, but they are
adding this in conjunction with some other existing conversational mode
media. Support of the hard of hearing is specified using real time text,
with a defined mechanism of interworking with PSAPs supported in the PS
domain. I see noone arguing for SMS usage in 3GPP or page mode messaging
by itself.

2)	I think we need to understand better the compatibility issues
with what you propose. How does the solution you propose avoid having to
upgrade every proxy / SBC along the path in order to have successful
conversational type communication? How does it interact with something
like outbound, where multiple outbound proxies exist? Does interworking
with SMS require the upgrade of all SMS systems in the same manner?=20

Regards

Keith

> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Jong Yul Kim
> Sent: 30 May 2011 13:54
> To: dispatch@ietf.org
> Subject: [dispatch] Emergency Text Messaging using SIP MESSAGE
>=20
> Hi everyone,
>=20
> This draft presents mechanisms to allow page-mode text messaging in
> emergency situations.
>=20
> An example of page-mode messaging is when a person sends SMS to an
> emergency number to get help. In this case, there needs to be a way
for
> the SMS message to reach the same call taker until the "conversation"
> ends.
>=20
> As emergency call centers are transitioning to a SIP-based solution,
the
> draft outlines a mechanism based on SIP MESSAGE method to deliver
page-
> mode messages consistently to a call taker.
>=20
> http://tools.ietf.org/html/draft-kim-dispatch-text-01
>=20
> Comments on the draft or which WG it should go to are much
appreciated.
> Please let us know your thoughts.
>=20
> Best regards,
>=20
> Jong Yul
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

From bruno.chatras@orange-ftgroup.com  Tue Jun  7 07:17:44 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7297111E8123 for ; Tue,  7 Jun 2011 07:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.347,  BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gCVe4hHjLXh for ; Tue,  7 Jun 2011 07:17:43 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7590811E8122 for ; Tue,  7 Jun 2011 07:17:43 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4DFC26D8015; Tue,  7 Jun 2011 16:18:59 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 42AB26C8003; Tue,  7 Jun 2011 16:18:59 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 7 Jun 2011 16:17:42 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 7 Jun 2011 16:17:41 +0200
Message-ID: <9ECCF01B52E7AB408A7EB8535264214102EE65B5@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <4DEE3280.4040102@bell-labs.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] SIP Load balancing (SIPLB) Charter proposal -	overload
Thread-Index: AcwlHVl9TxA2l+tnRd6zrtaX0utxpwAAEYqg
References: 	<9ECCF01B52E7AB408A7EB8535264214102E4435E@ftrdmel0.rd.francetelecom.fr>	 <9ECCF01B52E7AB408A7EB8535264214102EE6374@ftrdmel0.rd.francetelecom.fr> <4DEE3280.4040102@bell-labs.com>
From: 
To: 
X-OriginalArrivalTime: 07 Jun 2011 14:17:42.0504 (UTC) FILETIME=[AA1A6E80:01CC251D]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal -	overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jun 2011 14:17:44 -0000

Vijay,

I'm referring to=20

1) Use case and requirement document.
2) A document surveying SIP load balancing strategies in use today.
3) An architecture document showing sample SIP topologies.
4) Specification for SIP based overload scheme applicable to a=20
   signaling-only SIP server.
5) Specification for SIP based overload scheme applicable to a
   media-based SIP server.


> -----Message d'origine-----
> De=A0: Vijay K. Gurbani [mailto:vkg@bell-labs.com]
> Envoy=E9=A0: mardi 7 juin 2011 16:15
> =C0=A0: CHATRAS Bruno RD-CORE-ISS
> Cc=A0: partr@cisco.com; dispatch@ietf.org
> Objet=A0: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal -
> overload
>=20
> Bruno: Thank you for your feedback.  More inline.
>=20
> On 06/07/2011 04:18 AM, bruno.chatras@orange-ftgroup.com wrote:
> > Items 4 and 5 are referring to an overload scheme rather than a load
> > balancing scheme. Any reason for that? Typo?
>=20
> Item 4 ("As SIP request ... as well as media?") refers to load
> balancing.  I cannot find item 5 (if you are referring to
> the list of considerations, there are four items there. If
> you are referring to something else, please let me know what
> it is).
>=20
> > Same comment applies to the last two milestones
>=20
> Ooops, this is embarrassing; sorry.  Indeed, the last two milestones
> relate to load balancing and should say the following:
>=20
> Feb 2013  Submit signaling based SIP load balancing solution to IESG =
as
>            Proposed Standard RFC
> Feb 2013  Submit signaling and media based SIP load balancing solution
>            to IESG as Proposed Standard RFC
>=20
> Thank you.
>=20
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
> Web:   http://ect.bell-labs.com/who/vkg/

From vkg@bell-labs.com  Tue Jun  7 07:20:43 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8641311E812F for ; Tue,  7 Jun 2011 07:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjotW+CLf5K5 for ; Tue,  7 Jun 2011 07:20:42 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id E01F711E8138 for ; Tue,  7 Jun 2011 07:20:37 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p57EKToF008569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Jun 2011 09:20:29 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p57EKSEL015918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Jun 2011 09:20:29 -0500
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p57EKSL6001156; Tue, 7 Jun 2011 09:20:28 -0500 (CDT)
Message-ID: <4DEE33C3.7090703@bell-labs.com>
Date: Tue, 07 Jun 2011 09:20:51 -0500
From: "Vijay K. Gurbani" 
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: bruno.chatras@orange-ftgroup.com
References: 	<9ECCF01B52E7AB408A7EB8535264214102E4435E@ftrdmel0.rd.francetelecom.fr>	 <9ECCF01B52E7AB408A7EB8535264214102EE6374@ftrdmel0.rd.francetelecom.fr> <4DEE3280.4040102@bell-labs.com> <9ECCF01B52E7AB408A7EB8535264214102EE65B5@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102EE65B5@ftrdmel0.rd.francetelecom.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal -	overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jun 2011 14:20:43 -0000

On 06/07/2011 09:17 AM, bruno.chatras@orange-ftgroup.com wrote:
> Vijay,
>
> I'm referring to
>
> 1) Use case and requirement document.
> 2) A document surveying SIP load balancing strategies in use today.
> 3) An architecture document showing sample SIP topologies.
> 4) Specification for SIP based overload scheme applicable to a
>     signaling-only SIP server.
> 5) Specification for SIP based overload scheme applicable to a
>     media-based SIP server.

Dear Bruno: OK, in that case, the 4,5 will be changed in the next
revisions of the charter to:

Feb 2013  Submit signaling based SIP load balancing solution to IESG as
             Proposed Standard.
Feb 2013  Submit signaling and media based SIP load balancing solution
            to IESG as Proposed Standard.

Thanks for catching this!

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/

From vkg@bell-labs.com  Tue Jun  7 08:00:56 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A086211E812A for ; Tue,  7 Jun 2011 08:00:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELFxS0KgOIpE for ; Tue,  7 Jun 2011 08:00:55 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 401F411E8123 for ; Tue,  7 Jun 2011 08:00:55 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p57F0nhf022662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Jun 2011 10:00:49 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p57F0ntd024323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Jun 2011 10:00:49 -0500
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p57F0m1D011864; Tue, 7 Jun 2011 10:00:49 -0500 (CDT)
Message-ID: <4DEE3D38.3080106@bell-labs.com>
Date: Tue, 07 Jun 2011 10:01:12 -0500
From: "Vijay K. Gurbani" 
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: bruno.chatras@orange-ftgroup.com
References: 	<9ECCF01B52E7AB408A7EB8535264214102E4435E@ftrdmel0.rd.francetelecom.fr>	 <9ECCF01B52E7AB408A7EB8535264214102EE636C@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102EE636C@ftrdmel0.rd.francetelecom.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jun 2011 15:00:56 -0000

On 06/07/2011 04:13 AM, bruno.chatras@orange-ftgroup.com wrote:
bruno> Comment: In the list of considerations that must be taken into 
account I
bruno> would add « Whether the load balancer is SIP-aware or not.
bruno>
partha> Till now, we are discussing about SIP-aware load balancer only.
partha> In case the load balancer is SIP-unaware, is it something like
partha> load-balance by open-loop model wherein there is no feedback 
required
partha> from downstream servers or load balance in the transport layer 
instead
partha> of SIP layer ?. Could you please explain your consideration in 
detail.
partha>
bruno> I was referring to a load balancer at the transport layer with
bruno> feedback from downstream servers./*

Dear Bruno: I envision a SIP-aware load balancer with feedback
mechanism, where the feedback is carried in SIP signaling.

More inline.

bruno> Question: Is the Charter intended to cover architectures with an 
in-path
bruno> load balancer in front of a farm of SIP servers only or is it 
expected
bruno> to cover as well other architectures where the load balancer is 
off-path
bruno> or even architectures where load balancing just relies on frequent
bruno> updates of the DNS?

My understanding is that service providers are loath to update DNS.
As such, a solution that does not depend on DNS is preferable.  This,
then, means that an in-path solution that does not require DNS would
be the most preferred.

I note that the LDF function you mention from [1] is a backward
feedback solution with the LDF updating the DNS periodically.

I think that it would be good to have substantive input from the
service provider community as well as the working group to
determine whether a solution that does not depend on DNS being
updated is preferred or not.

Thoughts?

[1] http://www.3gpp.org/ftp/Specs/archive/23_series/23.812/23812-115.zip

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/

From bruno.chatras@orange-ftgroup.com  Tue Jun  7 09:03:58 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0F821F84BA for ; Tue,  7 Jun 2011 09:03:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OT1c8E2qFXq for ; Tue,  7 Jun 2011 09:03:55 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5AC21F84C0 for ; Tue,  7 Jun 2011 09:03:55 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A79DB8B8007; Tue,  7 Jun 2011 17:59:49 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 7BF759B009F; Tue,  7 Jun 2011 17:51:31 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 7 Jun 2011 17:48:51 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 7 Jun 2011 17:48:51 +0200
Message-ID: <9ECCF01B52E7AB408A7EB8535264214102F28BBD@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <4DEE33C3.7090703@bell-labs.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] SIP Load balancing (SIPLB) Charter proposal -	overload
Thread-Index: AcwlHil5dPoUEZgyTo6Een//xBnM9gAC8T8w
References: 	<9ECCF01B52E7AB408A7EB8535264214102E4435E@ftrdmel0.rd.francetelecom.fr>	 <9ECCF01B52E7AB408A7EB8535264214102EE6374@ftrdmel0.rd.francetelecom.fr> <4DEE3280.4040102@bell-labs.com> <9ECCF01B52E7AB408A7EB8535264214102EE65B5@ftrdmel0.rd.francetelecom.fr> <4DEE33C3.7090703@bell-labs.com>
From: 
To: 
X-OriginalArrivalTime: 07 Jun 2011 15:48:51.0925 (UTC) FILETIME=[6621D850:01CC252A]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal -	overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jun 2011 16:03:58 -0000

OK that's clear now.=20

By the way, I think that interactions between load balancing and =
overload detection should be added to the list of considerations to be =
taken into account.

Bruno



> -----Message d'origine-----
> De=A0: Vijay K. Gurbani [mailto:vkg@bell-labs.com]
> Envoy=E9=A0: mardi 7 juin 2011 16:21
> =C0=A0: CHATRAS Bruno RD-CORE-ISS
> Cc=A0: partr@cisco.com; dispatch@ietf.org
> Objet=A0: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal -
> overload
>=20
> On 06/07/2011 09:17 AM, bruno.chatras@orange-ftgroup.com wrote:
> > Vijay,
> >
> > I'm referring to
> >
> > 1) Use case and requirement document.
> > 2) A document surveying SIP load balancing strategies in use today.
> > 3) An architecture document showing sample SIP topologies.
> > 4) Specification for SIP based overload scheme applicable to a
> >     signaling-only SIP server.
> > 5) Specification for SIP based overload scheme applicable to a
> >     media-based SIP server.
>=20
> Dear Bruno: OK, in that case, the 4,5 will be changed in the next
> revisions of the charter to:
>=20
> Feb 2013  Submit signaling based SIP load balancing solution to IESG =
as
>              Proposed Standard.
> Feb 2013  Submit signaling and media based SIP load balancing solution
>             to IESG as Proposed Standard.
>=20
> Thanks for catching this!
>=20
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
> Web:   http://ect.bell-labs.com/who/vkg/

From bruno.chatras@orange-ftgroup.com  Tue Jun  7 09:04:20 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4007221F84C7 for ; Tue,  7 Jun 2011 09:04:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0heMHMFNCQ6k for ; Tue,  7 Jun 2011 09:04:17 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF1D21F84BA for ; Tue,  7 Jun 2011 09:04:17 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0E2D98D0002; Tue,  7 Jun 2011 17:59:55 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 01C929B0008; Tue,  7 Jun 2011 17:55:30 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 7 Jun 2011 17:54:13 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 7 Jun 2011 17:54:13 +0200
Message-ID: <9ECCF01B52E7AB408A7EB8535264214102F28BC2@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <4DEE3D38.3080106@bell-labs.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] SIP Load balancing (SIPLB) Charter proposal
Thread-Index: AcwlI7mmed+XiSHkQYGxFFc59kn/+QABrDoA
References: 	<9ECCF01B52E7AB408A7EB8535264214102E4435E@ftrdmel0.rd.francetelecom.fr>	 <9ECCF01B52E7AB408A7EB8535264214102EE636C@ftrdmel0.rd.francetelecom.fr> <4DEE3D38.3080106@bell-labs.com>
From: 
To: 
X-OriginalArrivalTime: 07 Jun 2011 15:54:13.0472 (UTC) FILETIME=[25CA0600:01CC252B]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jun 2011 16:04:20 -0000

Vijay,

Speaking as a representative of a Service Provider, I can tell you that =
we are interested in DNS-based solutions. I believe that the WG should =
address both types of solutions.

Bruno

> -----Message d'origine-----
> De=A0: Vijay K. Gurbani [mailto:vkg@bell-labs.com]
> Envoy=E9=A0: mardi 7 juin 2011 17:01
> =C0=A0: CHATRAS Bruno RD-CORE-ISS
> Cc=A0: partr@cisco.com; dispatch@ietf.org
> Objet=A0: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
>=20
> On 06/07/2011 04:13 AM, bruno.chatras@orange-ftgroup.com wrote:
> bruno> Comment: In the list of considerations that must be taken into
> account I
> bruno> would add =AB Whether the load balancer is SIP-aware or not.
> bruno>
> partha> Till now, we are discussing about SIP-aware load balancer =
only.
> partha> In case the load balancer is SIP-unaware, is it something like
> partha> load-balance by open-loop model wherein there is no feedback
> required
> partha> from downstream servers or load balance in the transport layer
> instead
> partha> of SIP layer ?. Could you please explain your consideration in
> detail.
> partha>
> bruno> I was referring to a load balancer at the transport layer with
> bruno> feedback from downstream servers./*
>=20
> Dear Bruno: I envision a SIP-aware load balancer with feedback
> mechanism, where the feedback is carried in SIP signaling.
>=20
> More inline.
>=20
> bruno> Question: Is the Charter intended to cover architectures with =
an
> in-path
> bruno> load balancer in front of a farm of SIP servers only or is it
> expected
> bruno> to cover as well other architectures where the load balancer is
> off-path
> bruno> or even architectures where load balancing just relies on
> frequent
> bruno> updates of the DNS?
>=20
> My understanding is that service providers are loath to update DNS.
> As such, a solution that does not depend on DNS is preferable.  This,
> then, means that an in-path solution that does not require DNS would
> be the most preferred.
>=20
> I note that the LDF function you mention from [1] is a backward
> feedback solution with the LDF updating the DNS periodically.
>=20
> I think that it would be good to have substantive input from the
> service provider community as well as the working group to
> determine whether a solution that does not depend on DNS being
> updated is preferred or not.
>=20
> Thoughts?
>=20
> [1] http://www.3gpp.org/ftp/Specs/archive/23_series/23.812/23812-
> 115.zip
>=20
> Thanks,
>=20
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
> Web:   http://ect.bell-labs.com/who/vkg/

From vkg@bell-labs.com  Tue Jun  7 10:04:08 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0717411E81E0 for ; Tue,  7 Jun 2011 10:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czhmIcvmFUVa for ; Tue,  7 Jun 2011 10:04:04 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id E946211E81DF for ; Tue,  7 Jun 2011 10:04:03 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p57H41Wt005214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Jun 2011 12:04:01 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p57H41sf026204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Jun 2011 12:04:01 -0500
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p57H40PU007081; Tue, 7 Jun 2011 12:04:00 -0500 (CDT)
Message-ID: <4DEE5A18.10003@bell-labs.com>
Date: Tue, 07 Jun 2011 12:04:24 -0500
From: "Vijay K. Gurbani" 
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: bruno.chatras@orange-ftgroup.com
References: 	<9ECCF01B52E7AB408A7EB8535264214102E4435E@ftrdmel0.rd.francetelecom.fr>	 <9ECCF01B52E7AB408A7EB8535264214102EE6374@ftrdmel0.rd.francetelecom.fr> <4DEE3280.4040102@bell-labs.com> <9ECCF01B52E7AB408A7EB8535264214102EE65B5@ftrdmel0.rd.francetelecom.fr> <4DEE33C3.7090703@bell-labs.com> <9ECCF01B52E7AB408A7EB8535264214102F28BBD@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102F28BBD@ftrdmel0.rd.francetelecom.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal -	overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jun 2011 17:04:08 -0000

On 06/07/2011 10:48 AM, bruno.chatras@orange-ftgroup.com wrote:
> OK that's clear now.
>
> By the way, I think that interactions between load balancing and
> overload detection should be added to the list of considerations to
> be taken into account.

Bruno: Yes, I agree.  I think we should do more than list it in the
consideration section --- I think that the use case and requirements
document should have a section on the interaction between load balancing
and overload control.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/

From vkg@bell-labs.com  Tue Jun  7 10:05:46 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C732211E81DF for ; Tue,  7 Jun 2011 10:05:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIMtcc+UfHk3 for ; Tue,  7 Jun 2011 10:05:46 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 2224E11E8153 for ; Tue,  7 Jun 2011 10:05:46 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p57H5eAD021139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Jun 2011 12:05:40 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p57H5e6H027226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Jun 2011 12:05:40 -0500
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p57H5dSE008362; Tue, 7 Jun 2011 12:05:40 -0500 (CDT)
Message-ID: <4DEE5A7C.7030407@bell-labs.com>
Date: Tue, 07 Jun 2011 12:06:04 -0500
From: "Vijay K. Gurbani" 
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: bruno.chatras@orange-ftgroup.com
References: 	<9ECCF01B52E7AB408A7EB8535264214102E4435E@ftrdmel0.rd.francetelecom.fr>	 <9ECCF01B52E7AB408A7EB8535264214102EE636C@ftrdmel0.rd.francetelecom.fr> <4DEE3D38.3080106@bell-labs.com> <9ECCF01B52E7AB408A7EB8535264214102F28BC2@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102F28BC2@ftrdmel0.rd.francetelecom.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jun 2011 17:05:46 -0000

On 06/07/2011 10:54 AM, bruno.chatras@orange-ftgroup.com wrote:
> Vijay,
>
> Speaking as a representative of a Service Provider, I can tell you
> that we are interested in DNS-based solutions. I believe that the WG
> should address both types of solutions.

Bruno: OK.  This is good feedback to consider.  Thanks much!

Anyone else ...

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/

From charles.newyork@gmail.com  Tue Jun  7 15:15:48 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74A611E80D6; Tue,  7 Jun 2011 15:15:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZMTr8m0voF1; Tue,  7 Jun 2011 15:15:48 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C31B511E80A8; Tue,  7 Jun 2011 15:15:47 -0700 (PDT)
Received: by iyn15 with SMTP id 15so6389392iyn.31 for ; Tue, 07 Jun 2011 15:15:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=L/Zrgkp6mlo1cyFAXWRn+rNIfuD6TQqOzVbKgul7Ato=; b=qnEKhD3KMYurd9wkCudUGa9CWRqXhDtCU66gmQ+FbvNuSTskAVeNIEOIZYcA9HB4t/ pcZZKxDtdq6r50emknZ6+A6esHqhtqQsAkjpo/El8PqirUIjsiG2Hu0dqsGBxSxezec7 +5abK5lLdW77j0SIjm7oDzFFVb7cksvi2AuIM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=rkXpN/lLr5c3glt/mieIxSYZ68DLzbPXP2f33bcjdykx/n0Ty9N4llH8Mch/6BgfwC cV9WzK6KpMgxdo0CY+HkROsv4NoPuFo9eXUHBVWZjtR3vnzFmVmhelxDMwRIGzR4ou/n rNZ1fj7oKxoqxOvEfLVyMrEQR9+CobKtkJapw=
Received: by 10.43.63.10 with SMTP id xc10mr11390111icb.303.1307484947121; Tue, 07 Jun 2011 15:15:47 -0700 (PDT)
MIME-Version: 1.0
Sender: charles.newyork@gmail.com
Received: by 10.42.228.136 with HTTP; Tue, 7 Jun 2011 15:15:27 -0700 (PDT)
In-Reply-To: <4DECCCB1.8060705@cisco.com>
References:  <4DECCCB1.8060705@cisco.com>
From: Charles Shen 
Date: Tue, 7 Jun 2011 18:15:27 -0400
X-Google-Sender-Auth: 1scKhVYJUiv3IwHfbNIsl47mdF8
Message-ID: 
To: DISPATCH , "Paul Kyzivat (pkyzivat)" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: sip-overload@ietf.org
Subject: [dispatch] Fwd: [sip-overload] draft-shen-soc-avalanche-restart-overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jun 2011 22:15:49 -0000

Thank you Paul, I am forwarding it to Dispatch.

Charles

---------- Forwarded message ----------
From: Paul Kyzivat 
Date: Mon, Jun 6, 2011 at 8:48 AM
Subject: Re: [sip-overload] draft-shen-soc-avalanche-restart-overload
To: sip-overload@ietf.org


Charles,

While this problem certainly falls into the general category of sip
overload control, ISTM that it has a substantially different
constituency than has been involved in the other overload control
work. (Much of the impact is on individual UAs, which have not been of
significant concern in the other work.) So I do think it would be good
to take initial discussion into a forum that will get the attention of
affected parties.

Something that proposes to change the behavior of UAs when they
register will almost certainly have to be dealt with in sipcore
eventually. But while initially scoping the problem, dispatch seems
the appropriate place to me.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0Paul

On 6/5/2011 11:25 PM, Charles Shen wrote:
>
> Hi all,
>
> The IETF80 minutes below show mixed feedbacks about the avalanche
> restart draft. I would therefore like to follow up discussing about
> the comments raised.
>
> 1. There is an explicite mention of the "Outbound proxy RFC" which
> "has timer to solve the issue". I assumed that means RFC5626 and took
> a second look at it. One section I found could be most relevant is
> Section 4.5 Flow Recovery, where it says each new registration "is
> done in much the same way as forming a brand new flow as described in
> Section 4.2; however, if there is a failure in forming this flow, the
> UA needs to wait a certain amount of time before retrying to form a
> flow to this particular next hop". The subsequent paragraphs in that
> section define a way to compute the backoff time.
>
> Back to Section 4.2, I did not find discussion about whether and how
> the *initial registation* should be randomized. If that is the case,
> the solution is different from what is presented in this avalanche
> restart draft. The mechanism in this draft seeks to avoid the initial
> storm of registration or similar message causing avalanche restart.
> And if this effort is successful, subsequent backoff might not be
> necessary, although I think inclusion of RFC5626 backoff timers would
> certainly increase robustness.
>
> 2. There is also a suggestion to discuss this in dispatch. Since
> "avalanche restart" is a problem described in the overload requirement
> RFC 5390, maybe AD and/or chairs can advice whether we should cross
> post this discussion or keep it in either one list for now.
>
> Thanks
>
> Charles
>
>
>
> On Thu, Apr 28, 2011 at 1:54 PM, Salvatore Loreto
>  =C2=A0wrote:
>>
>> Hi there,
>>
>> below the notes from the SoC session during the IETF80 meeting in Prague=
.
>> (I have already uploaded this initial version to ietf proceeding site)
>>
>> Please review them and submit any correction to the chairs by May 11.
>> The chairs have to send the notes toproceedings@ietf.org =C2=A0by May18t=
h.
>>
>> (many thanks to Partha for taking notes during the meeting)
>>
>> cheers
>> /Sal
>>
>> --
>> Salvatore Loreto
>> www.sloreto.com
>>
>
> snipped ...
>
>>
>>
>> Avalanche restart overload =C2=A0(Presenter: Arate Koike)
>> ------------------------
>> Hadriel: Let register has restart-timer instead of subscribe as it is
>> register avalanche. SUBSCRIBE may not go to Registrar.
>> Partha: SUBSCRIBE message itself may overload
>>
>> Open discussion:
>> Hadriel: Mention this problem may not be solved by the proposed mechanis=
m.
>> Partha: The problem solved by Avalanche is in the boot up time only.
>> Hadriel, Robert: Outbound proxy RFC has timer to solve the issue and it =
is
>> not generic
>> Partha: Agreed, It will not solve all the problem
>> Robert: Discuss in dispatch
>>
>> _______________________________________________
>> sip-overload mailing list
>> sip-overload@ietf.org
>> https://www.ietf.org/mailman/listinfo/sip-overload
>>
>
>
>
> Thanks
>
> Charles
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload

_______________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload

From arnoud.vanwijk@realtimetext.org  Wed Jun  8 00:59:40 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4933121F8563 for ; Wed,  8 Jun 2011 00:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.948
X-Spam-Level: 
X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnA7lEWBvSqv for ; Wed,  8 Jun 2011 00:59:39 -0700 (PDT)
Received: from mx-in02.nouzelle.com (mx-in02.nouzelle.com [87.119.194.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1585B21F855E for ; Wed,  8 Jun 2011 00:59:38 -0700 (PDT)
Received: from internal02.nouzelle.com (mail.local [172.29.32.13]) by mx-in02.nouzelle.com (Postfix) with ESMTP id C0D26102156C5 for ; Wed,  8 Jun 2011 09:59:36 +0200 (CEST)
Received: from mailscan.nouzelle.com (unknown [172.29.32.10]) by internal02.nouzelle.com (Postfix) with ESMTP id B26671021A48C for ; Wed,  8 Jun 2011 09:59:36 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at nouzelle.com
Received: from internal02.nouzelle.com ([172.29.32.13]) by mailscan.nouzelle.com (mailscan.nouzelle.com [172.29.32.10]) (amavisd-new, port 10026) with ESMTP id rqHgdvBC9bZi for ; Wed,  8 Jun 2011 09:59:35 +0200 (CEST)
Received: from arnoud-van-wijks-macbook-pro.local (541BD3CF.cm-5-4d.dynamic.ziggo.nl [84.27.211.207]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by internal02.nouzelle.com (Postfix) with ESMTPSA id CD8661021A48B for ; Wed,  8 Jun 2011 09:59:35 +0200 (CEST)
Message-ID: <4DEF2BE7.9090306@realtimetext.org>
Date: Wed, 08 Jun 2011 09:59:35 +0200
From: Arnoud van Wijk 
Organization: R3TF
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: dispatch@ietf.org
References: <4DDE3268.2030307@realtimetext.org>
In-Reply-To: <4DDE3268.2030307@realtimetext.org>
Content-Type: multipart/alternative; boundary="------------060509060006030102020301"
Subject: [dispatch] Text media handling in RTP based real-time conferences
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: arnoud.vanwijk@realtimetext.org
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Jun 2011 07:59:40 -0000

This is a multi-part message in MIME format.
--------------060509060006030102020301
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi everybody,

Since this draft was submitted in March ago, I like to ask DISPATCH if 
the AVTCORE WG is the best WG for it.
I think so, since this does handle media handling in conferences.
We have edited this draft based on the discussions in AVT core in march 
about SSRC multiplexing.

It is very important that when using RTT streams in a multiparty call 
that it will work with all SIP based call control environments.
I feel that we need together with AVT to work out the details to ensure 
that this remains possible.

Several solutions are currently being implemented in RTT systems by 
several companies and the longer we wait..the harder it gets to ensure 
the best implementation to be used.

So, this is quite important for real-world cases.

I am looking forward to your feedback as always.

sincerely

Arnoud van Wijk



> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : Text media handling in RTP based real-time conferences
> 	Author(s)       : G. Hellstrom, A. Wijk
> 	Filename        : draft-hellstrom-text-conference-04.txt
> 	Pages           : 9
> 	Date            : 2011-03-14
>
> This memo specifies methods for text media handling in multi-party
> calls, where the text is carried by the RTP protocol.  Real-time text
> is carried in a time-sampled mode according to RFC 4103.  Centralized
> multi-party handling of real-time text is achieved through a media
> control unit coordinating multiple RTP text streams into one single
> stream RTP session, identifying each stream with its own CSRC.
> Identification for the streams are provided through the RTCP
> messages.  This mechanism enables the receiving application to
> present the received real-time text medium in different ways
> according to user preferences.  Some presentation related features
> are also described explaining suitable variations of transmission and
> presentation of text.  Call control features are described for the
> SIP environment, while the transport mechanisms should be suitable
> for any IP based call control environment using RTP transport.  Two
> alternative methods using a single RTP stream and source
> identification inline in the text stream are also described.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hellstrom-text-conference-04.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> 
>


--------------060509060006030102020301
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
    
  
  
    Hi everybody,

    

    Since this draft was submitted in March ago, I like to ask DISPATCH
    if the AVTCORE WG is the best WG for it.

    I think so, since this does handle media handling in conferences.

    We have edited this draft based on the discussions in AVT core in
    march about SSRC multiplexing.

    

    It is very important that when using RTT streams in a multiparty
    call that it will work with all SIP based call control environments.

    I feel that we need together with AVT to work out the details to
    ensure that this remains possible.

    

    Several solutions are currently being implemented in RTT systems by
    several companies and the longer we wait..the harder it gets to
    ensure the best implementation to be used.

    

    So, this is quite important for real-world cases.

    

    I am looking forward to your feedback as always.

    

    sincerely

    

    Arnoud van Wijk

    

    

    

    

      
A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Text media handling in RTP based real-time conferences
	Author(s)       : G. Hellstrom, A. Wijk
	Filename        : draft-hellstrom-text-conference-04.txt
	Pages           : 9
	Date            : 2011-03-14

This memo specifies methods for text media handling in multi-party
calls, where the text is carried by the RTP protocol.  Real-time text
is carried in a time-sampled mode according to RFC 4103.  Centralized
multi-party handling of real-time text is achieved through a media
control unit coordinating multiple RTP text streams into one single
stream RTP session, identifying each stream with its own CSRC.
Identification for the streams are provided through the RTCP
messages.  This mechanism enables the receiving application to
present the received real-time text medium in different ways
according to user preferences.  Some presentation related features
are also described explaining suitable variations of transmission and
presentation of text.  Call control features are described for the
SIP environment, while the transport mechanisms should be suitable
for any IP based call control environment using RTP transport.  Two
alternative methods using a single RTP stream and source
identification inline in the text stream are also described.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hellstrom-text-conference-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


      

        
<ftp://ftp.ietf.org/internet-drafts/draft-hellstrom-text-conference-04.txt>

      

    

    

  


--------------060509060006030102020301--

From R.Jesske@telekom.de  Wed Jun  8 03:14:21 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E27011E8097 for ; Wed,  8 Jun 2011 03:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.248
X-Spam-Level: 
X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFxonurfQuYg for ; Wed,  8 Jun 2011 03:14:20 -0700 (PDT)
Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF4011E8077 for ; Wed,  8 Jun 2011 03:14:19 -0700 (PDT)
Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 08 Jun 2011 12:12:05 +0200
Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.233]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Wed, 8 Jun 2011 12:12:05 +0200
From: 
To: 
Date: Wed, 8 Jun 2011 12:12:04 +0200
Thread-Topic: [dispatch] charter proposal: SIP end-to-end Session Identifier
Thread-Index: Acwk9W3xWh8EibNIS4Cb/M/ve+4NeQAyKJXw
Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D088DCC2742@HE111648.emea1.cds.t-internal.com>
References: <4DDA0388.60702@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A415@ESESSCMS0356.eemea.ericsson.se> <006501cc2464$5e4f5a10$1aee0e30$@us> 
In-Reply-To: 
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: multipart/alternative; boundary="_000_580BEA5E3B99744AB1F5BFF5E9A3C67D088DCC2742HE111648emea1_"
MIME-Version: 1.0
Subject: Re: [dispatch] charter proposal: SIP end-to-end Session Identifier
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Jun 2011 10:14:21 -0000

--_000_580BEA5E3B99744AB1F5BFF5E9A3C67D088DCC2742HE111648emea1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Sal,
I'm also fully supporting that work. Thank you for the work you did on char=
ter proposal I'm fine with the proposal.

Best Regards

Roland


Mit freundlichen Gr=FC=DFen
Roland Jesske





Deutsche Telekom Netzproduktion GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske
Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt
+49 6151 58 12766 (Tel.)
+49 391 580 133 831 (Fax)
+49 171 8618-445 (Mobil)
E-Mail: r.jesske@telekom.de
www.telekom.de

Erleben, was verbindet.

Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)
Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe=
is, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft Bonn
USt-IdNr. DE 814645262



Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede=
 E-Mail drucken.



________________________________
Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im Auftra=
g von Xavier Marjou
Gesendet: Dienstag, 7. Juni 2011 11:28
An: DISPATCH list
Betreff: Re: [dispatch] charter proposal: SIP end-to-end Session Identifier

+1

On Mon, Jun 6, 2011 at 6:11 PM, Richard Shockey > wrote:
Long Long overdue ..  +1

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:d=
ispatch-bounces@ietf.org] On Behalf
Of Christer Holmberg
Sent: Monday, June 06, 2011 10:49 AM
To: Salvatore Loreto; dispatch@ietf.org
Subject: Re: [dispatch] charter proposal: SIP end-to-end Session Identifier

Hi,

I support the charter proposal. I think this is an important feature.

Regards,

Christer

________________________________
From: dispatch-bounces@ietf.org [dispatch=
-bounces@ietf.org] On Behalf Of
Salvatore Loreto [salvatore.loreto@ericsson.com]
Sent: Monday, May 23, 2011 9:49 AM
To: dispatch@ietf.org
Subject: [dispatch] charter proposal: SIP end-to-end Session Identifier

Hi there,
below a charter proposal for a new wg working on End-to-end Session
Identifier in SIP.

In an effort to make progress and to facilitate the discussion
we have also created an Internet Draft that captures, at a high level,
the requirements and use cases.
(It was submitted by Paul E. Jones last Friday; here the link:
http://www.ietf.org/id/draft-jones-ipmc-session-id-reqts-00.txt )

cheers
/Sal
End-to-end Session Identifier in SIP (charter proposal )
----------------------------------------------

The end-to-end Session Identifier in an SIP-based multimedia communication
refers to the ability
for endpoints, intermediate devices, and management and monitoring system t=
o
identify
and correlate SIP messages and dialogs of the same higher-level end-to-end
"communication
session" across multiple SIP devices and hops.

Unfortunately, there are a number of factors that contribute to the fact
that the current
dialog identifiers as defined in SIP is not suitable for end-to-end session
identification.
Perhaps the most important factor worth describing is that in real-world
deployments devices like Session Border Controllers (SBC) often change the
current call
identifiers (e.g., the From-tag and To-tag that are used in conjunction wit=
h
the Call-ID header
to make the dialog-id) as the session signaling passes through.


An end-to-end Session Identifier should allow the possibility to identify
the communication session
from the point of origin, passing through any number of intermediaries, to
the ultimate point
of termination. It should have the same aim as the From-tag, To-tag and
Call-ID conjunction,
but should not be mangled by intermediaries.

A SIP end-to-end Session Identifier has been considered as possible solutio=
n
of different use cases like
troubleshooting, billing, session tracking, session recording, media and
signaling correlation, and so forth.
Some of these requirements have also been identified and come directly from
other existing
working group within the RAI area (e.g. SIPRec, Splices).

Moreover, other SDOs have identified the need for SIP and H.323 to carry th=
e
same "session ID" value(s)
so that it is possible identify a call end-to end even when performing inte=
r
working between
protocols.


This group will first focus on a document that will identify, collect and
discuss all the
requirements and the use cases that have been identified.
The document may identify the possibility to design a general mechanism or
the need
to design multiple purpose built identifiers.
Once the needs are clear and identified, the working group will specify the
mechanism(s).


Specifically, the proposed working group will develop the following
deliverable:

 1.  A requirement and use case document with key consideration for SIP
Session
End-to-End identifier. The document will discuss the possibility of
designing
a general mechanism or the needs to design multiple purpose build
identifier.
 2.  Specification of new mechanism(s).

Goal and Milestone:
   October 2011 - Requirement and use case document sent to the IESG
(Information)

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--_000_580BEA5E3B99744AB1F5BFF5E9A3C67D088DCC2742HE111648emea1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hi=20
Sal,


I'm also fully supporting that work. Thank you for the work you did on cha=
rter=20
proposal I'm fine with the proposal.

 


Best=20
Regards


 


Roland
<=
/DIV>

 


Mit freundlichen Gr=FC=DFen
Roland Jesske


 


 


Deutsche Telekom Netzproduktion GmbH
Fixed Mobile Engine=
ering=20
Deutschland
Roland Jesske
Heinrich-Hertz-Stra=DFe 3-7, 64295=20
Darmstadt
+49 6151 58 12766 (Tel.)
+49 391 580 133 831 (Fax)
+49 1=
71=20
8618-445 (Mobil)
E-Mail: r.jesske@telekom.de
www.telekom.de

Erleben, was verbindet.

Deutsche Te=
lekom=20
Netzproduktion GmbH
Aufsichtsrat: Dr. Steffen Roehn=20
(Vorsitzender)
Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzen=
der),=20
Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB=20
14190
Sitz der Gesellschaft Bonn
USt-IdNr. DE 814645262


 


Gro=DFe Ver=E4nderungen fangen klein an =96 Re=
ssourcen=20
schonen und nicht jede E-Mail drucken.



 



  

  

  Von: dispatch-bounces@ietf.org=20
  [mailto:dispatch-bounces@ietf.org] Im Auftrag von Xavier=20
  Marjou
Gesendet: Dienstag, 7. Juni 2011 11:28
An: DIS=
PATCH=20
  list
Betreff: Re: [dispatch] charter proposal: SIP end-to-end=20
  Session Identifier


  
+1


  
On Mon, Jun 6, 2011 at 6:11 PM, Richard Shockey =
<richard@shockey.us> wrot=
e:

  
Long=20
    Long overdue ..  +1

-----Original Message-----
From: dispatch-bounces@ietf.org=
=20
    [mailto:dispatch-bounces@ietf.org=
] On=20
    Behalf
Of Christer Holmberg
Sent: Monday, June 06, 2011 10:49=20
    AM
To: Salvatore Loreto; dispatch@ietf.org
Subject: Re:=
=20
    [dispatch] charter proposal: SIP end-to-end Session Identifier

    

    

    

Hi,

I support the charter proposal. I think =
this is=20
    an important=20
    feature.

Regards,

Christer

_______________________=
_________
From:=20
    dispatch-bounces@ietf.org<=
/A> [dispatch-bounces@ietf.org=
] On=20
    Behalf Of
Salvatore Loreto [salvatore.loreto@ericsson=
.com]
Sent:=20
    Monday, May 23, 2011 9:49 AM
To: dispatch@ietf.org
Subject: [di=
spatch]=20
    charter proposal: SIP end-to-end Session Identifier

Hi=20
    there,
below a charter proposal for a new wg working on End-to-end=20
    Session
Identifier in SIP.

In an effort to make progress and =
to=20
    facilitate the discussion
we have also created an Internet Draft tha=
t=20
    captures, at a high level,
the requirements and use cases.
(It wa=
s=20
    submitted by Paul E. Jones last Friday; here the link:
http://www.ietf.org/id/draft-jones-ipmc-session-id-reqt=
s-00.txt=20
    )

cheers
/Sal
End-to-end Session Identifier in SIP (charte=
r=20
    proposal )
----------------------------------------------

The=
=20
    end-to-end Session Identifier in an SIP-based multimedia=20
    communication
refers to the ability
for endpoints, intermediate=20
    devices, and management and monitoring system to
identify
and=20
    correlate SIP messages and dialogs of the same higher-level=20
    end-to-end
"communication
session" across multiple SIP devices an=
d=20
    hops.

Unfortunately, there are a number of factors that contribu=
te to=20
    the fact
that the current
dialog identifiers as defined in SIP is=
 not=20
    suitable for end-to-end session
identification.
Perhaps the most=
=20
    important factor worth describing is that in real-world
deployments=
=20
    devices like Session Border Controllers (SBC) often change the
curre=
nt=20
    call
identifiers (e.g., the From-tag and To-tag that are used in=20
    conjunction with
the Call-ID header
to make the dialog-id) as the=
=20
    session signaling passes through.


An end-to-end Session=20
    Identifier should allow the possibility to identify
the communicatio=
n=20
    session
from the point of origin, passing through any number of=20
    intermediaries, to
the ultimate point
of termination. It should h=
ave=20
    the same aim as the From-tag, To-tag and
Call-ID conjunction,
but=
=20
    should not be mangled by intermediaries.

A SIP end-to-end Sessio=
n=20
    Identifier has been considered as possible solution
of different use=
=20
    cases like
troubleshooting, billing, session tracking, session recor=
ding,=20
    media and
signaling correlation, and so forth.
Some of these=20
    requirements have also been identified and come directly from
other=
=20
    existing
working group within the RAI area (e.g. SIPRec,=20
    Splices).

Moreover, other SDOs have identified the need for SIP =
and=20
    H.323 to carry the
same "session ID" value(s)
so that it is possi=
ble=20
    identify a call end-to end even when performing inter
working=20
    between
protocols.


This group will first focus on a docum=
ent=20
    that will identify, collect and
discuss all the
requirements and =
the=20
    use cases that have been identified.
The document may identify the=20
    possibility to design a general mechanism or
the need
to design=20
    multiple purpose built identifiers.
Once the needs are clear and=20
    identified, the working group will specify=20
    the
mechanism(s).


Specifically, the proposed working grou=
p=20
    will develop the following
deliverable:

 1.  A=20
    requirement and use case document with key consideration for=20
    SIP
Session
End-to-End identifier. The document will discuss the=
=20
    possibility of
designing
a general mechanism or the needs to desi=
gn=20
    multiple purpose build
identifier.
 2.  Specification o=
f new=20
    mechanism(s).

Goal and Milestone:
   October 2011 -=
=20
    Requirement and use case document sent to the=20
    IESG
(Information)

__________________________________________=
_____
dispatch=20
    mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
<=
BR>_______________________________________________
dispatch=20
    mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
<=
/DIV>



--_000_580BEA5E3B99744AB1F5BFF5E9A3C67D088DCC2742HE111648emea1_--

From mary.ietf.barnes@gmail.com  Wed Jun  8 08:14:45 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F1011E80E9 for ; Wed,  8 Jun 2011 08:14:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.598
X-Spam-Level: 
X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgnhRrSbnAuV for ; Wed,  8 Jun 2011 08:14:44 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC4B11E80E6 for ; Wed,  8 Jun 2011 08:14:44 -0700 (PDT)
Received: by vxg33 with SMTP id 33so607174vxg.31 for ; Wed, 08 Jun 2011 08:14:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2y2xMnciOcSpFPx/fZ4chNKI9cpvyEa6KvBu2haot+s=; b=L8CYgBOJdDnY8t76mzYxA3Xa7TkUR04RNVq4C2O95gLMWRH+duIQAkodvyaquZ8tUP mMNQ6ADdaf4dd0UjX6fSMTH3H0cztF4IUMd4GxEBB5APh3asuKuOaFnmD75WhdDWsvCu DrjHZdSb0++5gfS/tGH8qaYVg8p9ft4C8ek8I=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=a8MpVZ7rcqRg9Czifu3Q3/bw/6LsVpdPZ9p1anJLlR4lhOYY4hjJwVOw7DCqUvbEs5 aSDX0aNsReJcRL/v6S7Kfovle4R4FPEMBc2WL4RHu79nT+aihVTgj7TnCLmo6fT5ccad agyZ0v7QAz4Bx4LC9ppEa/aO1VqeZxJ9YFiyI=
MIME-Version: 1.0
Received: by 10.52.176.1 with SMTP id ce1mr1447532vdc.63.1307546083749; Wed, 08 Jun 2011 08:14:43 -0700 (PDT)
Received: by 10.52.158.39 with HTTP; Wed, 8 Jun 2011 08:14:43 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 8 Jun 2011 10:14:43 -0500
Message-ID: 
From: Mary Barnes 
To: DISPATCH 
Content-Type: multipart/alternative; boundary=bcaec517a812d9712604a534cbad
Subject: [dispatch] IETF-81 DISPATCH Topics/Areas of Focus
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Jun 2011 15:14:45 -0000

--bcaec517a812d9712604a534cbad
Content-Type: text/plain; charset=ISO-8859-1

Hi folks,

The following topics are tentatively allocated agenda time during the f2f
session in Quebec City:

1) End-to-End Session Identification:
http://www.ietf.org/mail-archive/web/dispatch/current/msg03321.html

2) Load Balancing:
http://www.ietf.org/mail-archive/web/dispatch/current/msg03649.html

3) BFCP for UDP:
http://www.ietf.org/mail-archive/web/dispatch/current/msg03653.html

 Note: agenda time will not be allocated if an updated document is not
available within two weeks.


4) Global Service Provider Identification Number:
http://www.ietf.org/id/draft-pfautz-service-provider-identifier-urn-00.txt

Note: This document needs WG review and feedback prior to the f2f meeting.



The following topics require more ML discussion and WG feedback in order to
determine the best way forward.

1) Application Specific Reason header:
http://www.ietf.org/mail-archive/web/dispatch/current/msg03658.html


Need further clarification of the problem that is trying to be solved  -
i.e., less focus on the proposed solution.   Need to identify the issues
with existing functionality (e.g., History-Info, CUSS work) that don't
satisfy the requirements for a solution.


2) 3892bis (*):  draft-loreto-dispatch-3892bis

There has still been virtually no discussion of this proposal.


3)  Real-time Text:
http://www.ietf.org/mail-archive/web/dispatch/current/msg03662.html


   - Presentation of Text Conversation in real-time and en-bloc form:
   draft-hellstrom-textpreview-08.txt
   - Text media handling in real-time conferences:
   draft-hellstrom-text-conference-04

Need some WG discussion and feedback.


The following documents are under review by the AD:

1)  IMEI URN:

   - Definition/Registration: draft-montemurro-gsma-imei-urn-06
   - Usage as an Instance ID:  draft-allen-dispatch-imei-urn-as-instanceid

The following topic has previously been discussed in ECRIT and no problem
statement was provided, thus no more discussion is necessary at this point:

1) Emergency Text Messaging using SIP MESSAGE:   draft-kim-dispatch-text-01


Regards,
Mary
DISPATCH WG co-chair

--bcaec517a812d9712604a534cbad
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi folks,



The follo=
wing topics are tentatively allocated agenda time during the f2f session in=
 Quebec City:

1)=A0End-to-E=
nd Session Identification: =A0=A0http://www.ietf.org/mail-archive/web/dispatch/current/ms=
g03321.html













Note: agenda time will not be allocated if an updated document is not avail=
able within two weeks. =A0


4) Global Service Provider Identification Number: =A0=A0http://www.ietf.org/id/draft-pfautz-service-provi=
der-identifier-urn-00.txt





Note: This document needs WG review and feedback prior to the f2f meeting.=
=A0



The following topics require more ML discussi=
on and WG feedback in order to determine the best way forward. =A0






Need further clarification of=A0the p=
roblem that is trying to be solved =A0- i.e., less focus on the proposed so=
lution. =A0 Need to identify the issues with existing functionality (e.g., =
History-Info, CUSS work) that don't satisfy the requirements for a solu=
tion.=A0




2) 3892bis (*=
): =A0draft-loreto-dispatch-38=
92bis






There has still been virtually no discussion of this proposal.=A0






  • Pr=
esentation of Text Conversation in real-time and en-bloc form:=A0draft-hellstrom-textpreview-08.txt=

    • 


  • Text med=
ia handling in real-time conferences: draft-hellstrom-text-conference-04
    • 




Need some WG discussion and feedback.=A0




The following documents are under review by the AD:
1) =A0IMEI URN:=A0
=

  • Definition/Registration:=A0draft-montemurro-gsma-imei-urn-06
    • 


  • Usage as an Instance ID: =A0draft-allen=
-dispatch-imei-urn-as-instanceid
The following t=
opic has previously been discussed in ECRIT and no problem statement was pr=
ovided, thus no more discussion is necessary at this point:




1) Emergency Text Messaging using SIP MESSAGE: =A0=A0draft-kim-dispatch-text-01





Regards,
Mary
DISPATCH WG co-chair





--bcaec517a812d9712604a534cbad--

From md3135@att.com  Wed Jun  8 13:39:12 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D479F11E8104 for ; Wed,  8 Jun 2011 13:39:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.524
X-Spam-Level: 
X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrhyMKPN8DjU for ; Wed,  8 Jun 2011 13:39:11 -0700 (PDT)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id CC43B11E8076 for ; Wed,  8 Jun 2011 13:39:11 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: md3135@att.com
X-Msg-Ref: server-13.tower-120.messagelabs.com!1307565550!21778341!1
X-StarScan-Version: 6.2.17; banners=-,-,-
X-Originating-IP: [144.160.20.146]
Received: (qmail 13791 invoked from network); 8 Jun 2011 20:39:11 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-13.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Jun 2011 20:39:11 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p58Kc4BU019888 for ; Wed, 8 Jun 2011 16:38:04 -0400
Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p58KbxEM019820 for ; Wed, 8 Jun 2011 16:37:59 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 8 Jun 2011 16:39:04 -0400
Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA0A43F39F@gaalpa1msgusr7e.ugd.att.com>
In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102F28BC2@ftrdmel0.rd.francetelecom.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] SIP Load balancing (SIPLB) Charter proposal
Thread-Index: AcwlI7mmed+XiSHkQYGxFFc59kn/+QABrDoAADxf01A=
References: 	<9ECCF01B52E7AB408A7EB8535264214102E4435E@ftrdmel0.rd.francetelecom.fr>	<9ECCF01B52E7AB408A7EB8535264214102EE636C@ftrdmel0.rd.francetelecom.fr><4DEE3D38.3080106@bell-labs.com> <9ECCF01B52E7AB408A7EB8535264214102F28BC2@ftrdmel0.rd.francetelecom.fr>
From: "DOLLY, MARTIN C (ATTSI)" 
To: , 
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Jun 2011 20:39:12 -0000

Bruno,

Do we really want to impact the DNS with a load balancing capability =
linked to overload control?

Martin

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On =
Behalf Of bruno.chatras@orange-ftgroup.com
Sent: Tuesday, June 07, 2011 11:54 AM
To: vkg@bell-labs.com
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal

Vijay,

Speaking as a representative of a Service Provider, I can tell you that =
we are interested in DNS-based solutions. I believe that the WG should =
address both types of solutions.

Bruno

> -----Message d'origine-----
> De=A0: Vijay K. Gurbani [mailto:vkg@bell-labs.com]
> Envoy=E9=A0: mardi 7 juin 2011 17:01
> =C0=A0: CHATRAS Bruno RD-CORE-ISS
> Cc=A0: partr@cisco.com; dispatch@ietf.org
> Objet=A0: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
>=20
> On 06/07/2011 04:13 AM, bruno.chatras@orange-ftgroup.com wrote:
> bruno> Comment: In the list of considerations that must be taken into
> account I
> bruno> would add =AB Whether the load balancer is SIP-aware or not.
> bruno>
> partha> Till now, we are discussing about SIP-aware load balancer =
only.
> partha> In case the load balancer is SIP-unaware, is it something like
> partha> load-balance by open-loop model wherein there is no feedback
> required
> partha> from downstream servers or load balance in the transport layer
> instead
> partha> of SIP layer ?. Could you please explain your consideration in
> detail.
> partha>
> bruno> I was referring to a load balancer at the transport layer with
> bruno> feedback from downstream servers./*
>=20
> Dear Bruno: I envision a SIP-aware load balancer with feedback
> mechanism, where the feedback is carried in SIP signaling.
>=20
> More inline.
>=20
> bruno> Question: Is the Charter intended to cover architectures with =
an
> in-path
> bruno> load balancer in front of a farm of SIP servers only or is it
> expected
> bruno> to cover as well other architectures where the load balancer is
> off-path
> bruno> or even architectures where load balancing just relies on
> frequent
> bruno> updates of the DNS?
>=20
> My understanding is that service providers are loath to update DNS.
> As such, a solution that does not depend on DNS is preferable.  This,
> then, means that an in-path solution that does not require DNS would
> be the most preferred.
>=20
> I note that the LDF function you mention from [1] is a backward
> feedback solution with the LDF updating the DNS periodically.
>=20
> I think that it would be good to have substantive input from the
> service provider community as well as the working group to
> determine whether a solution that does not depend on DNS being
> updated is preferred or not.
>=20
> Thoughts?
>=20
> [1] http://www.3gpp.org/ftp/Specs/archive/23_series/23.812/23812-
> 115.zip
>=20
> Thanks,
>=20
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
> Web:   http://ect.bell-labs.com/who/vkg/
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

From richard@shockey.us  Thu Jun  9 07:10:37 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F314511E8081 for ; Thu,  9 Jun 2011 07:10:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Level: 
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrNMaolsjtIc for ; Thu,  9 Jun 2011 07:10:33 -0700 (PDT)
Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id E064711E80B7 for ; Thu,  9 Jun 2011 07:10:32 -0700 (PDT)
Received: (qmail 22860 invoked by uid 0); 9 Jun 2011 14:10:26 -0000
Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy3.bluehost.com with SMTP; 9 Jun 2011 14:10:26 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=C5M+xadjZuTkzswS63XbeGLZHE0CHzHm4KOY7EO12EBdNeOF9Pf4eh9tYcbQWWb+TjEQcWmATLk4I9tiMmt51pEQDRVlS9h7igLSwujsvtYD8tOghuFj4uYtEII2kp2O;
Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1QUfwH-0007tS-Op for dispatch@ietf.org; Thu, 09 Jun 2011 08:10:26 -0600
From: "Richard Shockey" 
To: 
Date: Thu, 9 Jun 2011 10:10:25 -0400
Message-ID: <001801cc26ae$fb0a4120$f11ec360$@us>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcwhKbdT7sIPWpxhS7eIWaCrJJLfFgFgKJcg
Content-Language: en-us
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us}
Subject: [dispatch] Request for input. FW: I-D Action: draft-pfautz-service-provider-identifier-urn-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jun 2011 14:10:37 -0000

As some of you may have seen from the proposed DISPATCH agenda, this
document is proposed for discussion. It is in a early draft stage and needs
comment and community input.

That said I want to strongly support both the concept and the direction this
draft is taking. It highlights and proposes a solution to an extremely
important problem in SIP interconnection among global SIP service providers.
The problem is who do you send the session to if, typically, all you have is
a E.164 number. 

OK some of you would say ..that is what ENUM was supposed to do and
certainly no one wants listen to me rant on about ENUM anymore, but the
problem of number translation in SIP service provider networks remains and
is a serious impediment to global deployments. 

There is substantial technical precedent for this type of solution. In the
North American Numbering Databases there is a Service Provider
Identification Code (SPID) that has proved very useful for SIP service
providers in deploying Network to Network Interconnection interfaces. The
very existence of this identifier has permitted interconnected SIP to expand
to nearly 30% of the US voice market according to 2010 data from US Federal
Communications Commission Statistics. This draft proposes to extend this
technique.

The elegance of this solution is that it does not propose any new protocols,
nor does it define what type of databases or class of users can use the URN.


As the draft points out, this concept has been discussed for some time in
various industry groups and has been discussed as part of the overall DRINKS
architecture. It is, IMHO, a "good thing". 



-----Original Message-----
From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]
On Behalf Of internet-drafts@ietf.org
Sent: Thursday, June 02, 2011 9:34 AM
To: i-d-announce@ietf.org
Subject: I-D Action: draft-pfautz-service-provider-identifier-urn-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : SP URN
	Author(s)       : Penn Pfautz
	Filename        :
draft-pfautz-service-provider-identifier-urn-00.txt
	Pages           : 5
	Date            : 2011-06-02

   This document requests a service provider identifier URN namespace.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pfautz-service-provider-identifier
-urn-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-pfautz-service-provider-identifier-
urn-00.txt
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


From bruno.chatras@orange-ftgroup.com  Thu Jun  9 07:55:32 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A9321F8509 for ; Thu,  9 Jun 2011 07:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level: 
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=0.260,  BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fm5Yw6nfFFfL for ; Thu,  9 Jun 2011 07:55:30 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 701EA21F8508 for ; Thu,  9 Jun 2011 07:55:30 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4076CFC4026; Thu,  9 Jun 2011 16:55:28 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 9CB16FC40F3; Thu,  9 Jun 2011 15:28:28 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 9 Jun 2011 15:28:26 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 9 Jun 2011 15:28:24 +0200
Message-ID: <9ECCF01B52E7AB408A7EB8535264214102F297ED@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA0A43F39F@gaalpa1msgusr7e.ugd.att.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] SIP Load balancing (SIPLB) Charter proposal
Thread-Index: AcwlI7mmed+XiSHkQYGxFFc59kn/+QABrDoAADxf01AAIw4MoA==
References: 	<9ECCF01B52E7AB408A7EB8535264214102E4435E@ftrdmel0.rd.francetelecom.fr>	<9ECCF01B52E7AB408A7EB8535264214102EE636C@ftrdmel0.rd.francetelecom.fr><4DEE3D38.3080106@bell-labs.com> <9ECCF01B52E7AB408A7EB8535264214102F28BC2@ftrdmel0.rd.francetelecom.fr> <14C85D6CCBE92743AF33663BF5D24EBA0A43F39F@gaalpa1msgusr7e.ugd.att.com>
From: 
To: , 
X-OriginalArrivalTime: 09 Jun 2011 13:28:26.0037 (UTC) FILETIME=[1CBCDE50:01CC26A9]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jun 2011 14:55:32 -0000

Hi Martin,
The load balancing capability can be implemented on dedicated DNS =
servers only. This does not put the service provider's DNS =
infrastructure at risk.
Bruno


> -----Message d'origine-----
> De=A0: DOLLY, MARTIN C (ATTSI) [mailto:md3135@att.com]
> Envoy=E9=A0: mercredi 8 juin 2011 22:39
> =C0=A0: CHATRAS Bruno RD-CORE-ISS; vkg@bell-labs.com
> Cc=A0: dispatch@ietf.org
> Objet=A0: RE: [dispatch] SIP Load balancing (SIPLB) Charter proposal
>=20
> Bruno,
>=20
> Do we really want to impact the DNS with a load balancing capability
> linked to overload control?
>=20
> Martin
>=20
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of bruno.chatras@orange-ftgroup.com
> Sent: Tuesday, June 07, 2011 11:54 AM
> To: vkg@bell-labs.com
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
>=20
> Vijay,
>=20
> Speaking as a representative of a Service Provider, I can tell you =
that
> we are interested in DNS-based solutions. I believe that the WG should
> address both types of solutions.
>=20
> Bruno
>=20
> > -----Message d'origine-----
> > De=A0: Vijay K. Gurbani [mailto:vkg@bell-labs.com]
> > Envoy=E9=A0: mardi 7 juin 2011 17:01
> > =C0=A0: CHATRAS Bruno RD-CORE-ISS
> > Cc=A0: partr@cisco.com; dispatch@ietf.org
> > Objet=A0: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
> >
> > On 06/07/2011 04:13 AM, bruno.chatras@orange-ftgroup.com wrote:
> > bruno> Comment: In the list of considerations that must be taken =
into
> > account I
> > bruno> would add =AB Whether the load balancer is SIP-aware or not.
> > bruno>
> > partha> Till now, we are discussing about SIP-aware load balancer
> only.
> > partha> In case the load balancer is SIP-unaware, is it something
> like
> > partha> load-balance by open-loop model wherein there is no feedback
> > required
> > partha> from downstream servers or load balance in the transport
> layer
> > instead
> > partha> of SIP layer ?. Could you please explain your consideration
> in
> > detail.
> > partha>
> > bruno> I was referring to a load balancer at the transport layer =
with
> > bruno> feedback from downstream servers./*
> >
> > Dear Bruno: I envision a SIP-aware load balancer with feedback
> > mechanism, where the feedback is carried in SIP signaling.
> >
> > More inline.
> >
> > bruno> Question: Is the Charter intended to cover architectures with
> an
> > in-path
> > bruno> load balancer in front of a farm of SIP servers only or is it
> > expected
> > bruno> to cover as well other architectures where the load balancer
> is
> > off-path
> > bruno> or even architectures where load balancing just relies on
> > frequent
> > bruno> updates of the DNS?
> >
> > My understanding is that service providers are loath to update DNS.
> > As such, a solution that does not depend on DNS is preferable.  =
This,
> > then, means that an in-path solution that does not require DNS would
> > be the most preferred.
> >
> > I note that the LDF function you mention from [1] is a backward
> > feedback solution with the LDF updating the DNS periodically.
> >
> > I think that it would be good to have substantive input from the
> > service provider community as well as the working group to
> > determine whether a solution that does not depend on DNS being
> > updated is preferred or not.
> >
> > Thoughts?
> >
> > [1] http://www.3gpp.org/ftp/Specs/archive/23_series/23.812/23812-
> > 115.zip
> >
> > Thanks,
> >
> > - vijay
> > --
> > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> > Email: vkg@{bell-labs.com,acm.org} / =
vijay.gurbani@alcatel-lucent.com
> > Web:   http://ect.bell-labs.com/who/vkg/
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From richard@shockey.us  Thu Jun  9 08:08:24 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CAD21F85D0 for ; Thu,  9 Jun 2011 08:08:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.32
X-Spam-Level: 
X-Spam-Status: No, score=-102.32 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3b+lFjR6caZ for ; Thu,  9 Jun 2011 08:08:20 -0700 (PDT)
Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id C0BBB21F8588 for ; Thu,  9 Jun 2011 08:08:19 -0700 (PDT)
Received: (qmail 12514 invoked by uid 0); 9 Jun 2011 15:08:19 -0000
Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy3.bluehost.com with SMTP; 9 Jun 2011 15:08:19 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=AcjhyRB+/zrFiyk5gSP0wmXPSUTCKcW1XaxP16YfKlEWRgu02ChYhT5yZdrvRNs8p4X15Id6+SYNtc43Z0R0DLGFClQrzaEM1eSHB3W0fVCp4WU2pGKvlEDP3eOCDXpK;
Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1QUgqJ-00059D-0J; Thu, 09 Jun 2011 09:08:19 -0600
From: "Richard Shockey" 
To: , , 
References: 	<9ECCF01B52E7AB408A7EB8535264214102E4435E@ftrdmel0.rd.francetelecom.fr>	<9ECCF01B52E7AB408A7EB8535264214102EE636C@ftrdmel0.rd.francetelecom.fr><4DEE3D38.3080106@bell-labs.com>	<9ECCF01B52E7AB408A7EB8535264214102F28BC2@ftrdmel0.rd.francetelecom.fr>	<14C85D6CCBE92743AF33663BF5D24EBA0A43F39F@gaalpa1msgusr7e.ugd.att.com> <9ECCF01B52E7AB408A7EB8535264214102F297ED@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102F297ED@ftrdmel0.rd.francetelecom.fr>
Date: Thu, 9 Jun 2011 11:08:18 -0400
Message-ID: <006d01cc26b7$1140ecc0$33c2c640$@us>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcwlI7mmed+XiSHkQYGxFFc59kn/+QABrDoAADxf01AAIw4MoAADqpCw
Content-Language: en-us
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us}
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jun 2011 15:08:24 -0000

Humm .. an application specific use of DNS technology in a closed =
controlled
environment.  I heard of these kind of things before.  Sounds like a
interesting idea. :-)=20

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On =
Behalf
Of bruno.chatras@orange-ftgroup.com
Sent: Thursday, June 09, 2011 9:28 AM
To: md3135@att.com; vkg@bell-labs.com
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal

Hi Martin,
The load balancing capability can be implemented on dedicated DNS =
servers
only. This does not put the service provider's DNS infrastructure at =
risk.
Bruno


> -----Message d'origine-----
> De=A0: DOLLY, MARTIN C (ATTSI) [mailto:md3135@att.com]
> Envoy=E9=A0: mercredi 8 juin 2011 22:39
> =C0=A0: CHATRAS Bruno RD-CORE-ISS; vkg@bell-labs.com
> Cc=A0: dispatch@ietf.org
> Objet=A0: RE: [dispatch] SIP Load balancing (SIPLB) Charter proposal
>=20
> Bruno,
>=20
> Do we really want to impact the DNS with a load balancing capability
> linked to overload control?
>=20
> Martin
>=20
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of bruno.chatras@orange-ftgroup.com
> Sent: Tuesday, June 07, 2011 11:54 AM
> To: vkg@bell-labs.com
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
>=20
> Vijay,
>=20
> Speaking as a representative of a Service Provider, I can tell you =
that
> we are interested in DNS-based solutions. I believe that the WG should
> address both types of solutions.
>=20
> Bruno
>=20
> > -----Message d'origine-----
> > De=A0: Vijay K. Gurbani [mailto:vkg@bell-labs.com]
> > Envoy=E9=A0: mardi 7 juin 2011 17:01
> > =C0=A0: CHATRAS Bruno RD-CORE-ISS
> > Cc=A0: partr@cisco.com; dispatch@ietf.org
> > Objet=A0: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
> >
> > On 06/07/2011 04:13 AM, bruno.chatras@orange-ftgroup.com wrote:
> > bruno> Comment: In the list of considerations that must be taken =
into
> > account I
> > bruno> would add =AB Whether the load balancer is SIP-aware or not.
> > bruno>
> > partha> Till now, we are discussing about SIP-aware load balancer
> only.
> > partha> In case the load balancer is SIP-unaware, is it something
> like
> > partha> load-balance by open-loop model wherein there is no feedback
> > required
> > partha> from downstream servers or load balance in the transport
> layer
> > instead
> > partha> of SIP layer ?. Could you please explain your consideration
> in
> > detail.
> > partha>
> > bruno> I was referring to a load balancer at the transport layer =
with
> > bruno> feedback from downstream servers./*
> >
> > Dear Bruno: I envision a SIP-aware load balancer with feedback
> > mechanism, where the feedback is carried in SIP signaling.
> >
> > More inline.
> >
> > bruno> Question: Is the Charter intended to cover architectures with
> an
> > in-path
> > bruno> load balancer in front of a farm of SIP servers only or is it
> > expected
> > bruno> to cover as well other architectures where the load balancer
> is
> > off-path
> > bruno> or even architectures where load balancing just relies on
> > frequent
> > bruno> updates of the DNS?
> >
> > My understanding is that service providers are loath to update DNS.
> > As such, a solution that does not depend on DNS is preferable.  =
This,
> > then, means that an in-path solution that does not require DNS would
> > be the most preferred.
> >
> > I note that the LDF function you mention from [1] is a backward
> > feedback solution with the LDF updating the DNS periodically.
> >
> > I think that it would be good to have substantive input from the
> > service provider community as well as the working group to
> > determine whether a solution that does not depend on DNS being
> > updated is preferred or not.
> >
> > Thoughts?
> >
> > [1] http://www.3gpp.org/ftp/Specs/archive/23_series/23.812/23812-
> > 115.zip
> >
> > Thanks,
> >
> > - vijay
> > --
> > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> > Email: vkg@{bell-labs.com,acm.org} / =
vijay.gurbani@alcatel-lucent.com
> > Web:   http://ect.bell-labs.com/who/vkg/
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


From dworley@avaya.com  Thu Jun  9 08:36:38 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764B811E80F2 for ; Thu,  9 Jun 2011 08:36:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.537
X-Spam-Level: 
X-Spam-Status: No, score=-103.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxEawr+TrT2h for ; Thu,  9 Jun 2011 08:36:37 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 8B86411E80EC for ; Thu,  9 Jun 2011 08:36:37 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFABDo8E2HCzI1/2dsb2JhbAA4ARqlaFN3rEgCjkEBjRiGIwSWFIsE
X-IronPort-AV: E=Sophos;i="4.65,341,1304308800"; d="scan'208";a="284134899"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Jun 2011 11:36:35 -0400
X-IronPort-AV: E=Sophos;i="4.65,341,1304308800"; d="scan'208";a="661286047"
Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 Jun 2011 11:36:36 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 9 Jun 2011 11:36:35 -0400
From: "Worley, Dale R (Dale)" 
To: Richard Shockey , "dispatch@ietf.org" 
Date: Thu, 9 Jun 2011 11:36:34 -0400
Thread-Topic: [dispatch] Request for input. FW: I-D Action: draft-pfautz-service-provider-identifier-urn-00.txt
Thread-Index: AcwhKbdT7sIPWpxhS7eIWaCrJJLfFgFgKJcgAAP7Xro=
Message-ID: 
References: <001801cc26ae$fb0a4120$f11ec360$@us>
In-Reply-To: <001801cc26ae$fb0a4120$f11ec360$@us>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dispatch] Request for input. FW: I-D Action:	draft-pfautz-service-provider-identifier-urn-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jun 2011 15:36:38 -0000

The syntax of the proposed URNs is odd.  As far as I can tell from your tex=
t, you want "urn:12345678".  What is the URN scheme?

But I see no strong need to introduce a new scheme, as organizations can ge=
t identifiers in an existing scheme:  Get a "private enterprise number" ass=
ignment, which gives you ownership of the 1.3.6.1.4.1.xxx Object Identifier=
 tree.  Then you can use all "oid" URNs under that tree.

E.g., my consulting company is identified by .

That has more overhead, but it also allows infinite sub-delegation, and it'=
s already standardized (RFC 3061).

Dale

From partr@cisco.com  Thu Jun  9 10:44:47 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F042A11E80EC for ; Thu,  9 Jun 2011 10:44:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level: 
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=0.600,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jktzP8gk9aGj for ; Thu,  9 Jun 2011 10:44:45 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4F011E812C for ; Thu,  9 Jun 2011 10:44:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=6155; q=dns/txt; s=iport; t=1307641485; x=1308851085; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=rwV4leI5LLB/f2QACxvYnmDojuG+T6j9V8f5USNT27M=; b=hd+1CuNK/SK8NP00TGMw/lEntNLe7Za/a7hUvoRoswB60LfVcw77/NAL 4FTFZShUkwZWs34kDR/Eso+g95JP9/CQe8uC7YcIRIBPHoCRROR2Kb+2P lKiYYvAwJySHz34PLj1NK5TXRX5jfV7X6LWBrqeV0VihqwfB8pwd1w2LC 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah8BADsG8U1Io8US/2dsb2JhbABTl0qOdHeIcaB6nhODLIJ3BIcGjnqLBA
X-IronPort-AV: E=Sophos;i="4.65,342,1304294400"; d="scan'208";a="93193614"
Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 09 Jun 2011 17:44:42 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p59HigYP029110; Thu, 9 Jun 2011 17:44:42 GMT
Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 9 Jun 2011 23:14:42 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 9 Jun 2011 23:14:41 +0530
Message-ID: 
In-Reply-To: <006d01cc26b7$1140ecc0$33c2c640$@us>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] SIP Load balancing (SIPLB) Charter proposal
Thread-Index: AcwlI7mmed+XiSHkQYGxFFc59kn/+QABrDoAADxf01AAIw4MoAADqpCwAAUcWcA=
References: 	<9ECCF01B52E7AB408A7EB8535264214102E4435E@ftrdmel0.rd.francetelecom.fr>	<9ECCF01B52E7AB408A7EB8535264214102EE636C@ftrdmel0.rd.francetelecom.fr><4DEE3D38.3080106@bell-labs.com>	<9ECCF01B52E7AB408A7EB8535264214102F28BC2@ftrdmel0.rd.francetelecom.fr>	<14C85D6CCBE92743AF33663BF5D24EBA0A43F39F@gaalpa1msgusr7e.ugd.att.com><9ECCF01B52E7AB408A7EB8535264214102F297ED@ftrdmel0.rd.francetelecom.fr> <006d01cc26b7$1140ecc0$33c2c640$@us>
From: "Parthasarathi R (partr)" 
To: "Richard Shockey" , , , 
X-OriginalArrivalTime: 09 Jun 2011 17:44:42.0150 (UTC) FILETIME=[E99D8460:01CC26CC]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jun 2011 17:44:47 -0000

Bruno,

Thanks for your information about DNS based SIP load balancing in 3GPP =
spec (in different mail thread).=20

IMO, There are two parts in feedback based SIP load balancing

1) Feedback value
2) Feedback protocol choice (SIP, DNS, SNMP)=20

The current mail thread is about feedback protocol which has to be used. =
I agree with you that it is possible for other protocols for SIP load =
balancing. We will add the consideration and discuss in detail about =
protocol choice to sort out the discussion.

I really didn't see the usage of DNS based load balancing mechanism in =
Enterprise deployment. But initially, I have explored to use SNMP to =
pass feedback value as a trap and I got the comments that SIP based =
feedback mechanism will reduce the dependency on another protocol stack =
in the system. I guess that the comment will apply for DNS as well and =
also FQDN in SIP URI is not mandatory in SIP.

Thanks
Partha

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On =
Behalf Of Richard Shockey
Sent: Thursday, June 09, 2011 8:38 PM
To: bruno.chatras@orange-ftgroup.com; md3135@att.com; vkg@bell-labs.com
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal


Humm .. an application specific use of DNS technology in a closed =
controlled environment.  I heard of these kind of things before.  Sounds =
like a interesting idea. :-)=20

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On =
Behalf Of bruno.chatras@orange-ftgroup.com
Sent: Thursday, June 09, 2011 9:28 AM
To: md3135@att.com; vkg@bell-labs.com
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal

Hi Martin,
The load balancing capability can be implemented on dedicated DNS =
servers only. This does not put the service provider's DNS =
infrastructure at risk.
Bruno


> -----Message d'origine-----
> De=A0: DOLLY, MARTIN C (ATTSI) [mailto:md3135@att.com] Envoy=E9=A0: =
mercredi=20
> 8 juin 2011 22:39 =C0=A0: CHATRAS Bruno RD-CORE-ISS; vkg@bell-labs.com =
Cc=A0
> : dispatch@ietf.org Objet=A0: RE: [dispatch] SIP Load balancing =
(SIPLB)=20
> Charter proposal
>=20
> Bruno,
>=20
> Do we really want to impact the DNS with a load balancing capability=20
> linked to overload control?
>=20
> Martin
>=20
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=20
> Behalf Of bruno.chatras@orange-ftgroup.com
> Sent: Tuesday, June 07, 2011 11:54 AM
> To: vkg@bell-labs.com
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
>=20
> Vijay,
>=20
> Speaking as a representative of a Service Provider, I can tell you=20
> that we are interested in DNS-based solutions. I believe that the WG=20
> should address both types of solutions.
>=20
> Bruno
>=20
> > -----Message d'origine-----
> > De=A0: Vijay K. Gurbani [mailto:vkg@bell-labs.com] Envoy=E9=A0: =
mardi 7=20
> > juin 2011 17:01 =C0=A0: CHATRAS Bruno RD-CORE-ISS Cc=A0: =
partr@cisco.com;=20
> > dispatch@ietf.org Objet=A0: Re: [dispatch] SIP Load balancing =
(SIPLB)=20
> > Charter proposal
> >
> > On 06/07/2011 04:13 AM, bruno.chatras@orange-ftgroup.com wrote:
> > bruno> Comment: In the list of considerations that must be taken=20
> > bruno> into
> > account I
> > bruno> would add =AB Whether the load balancer is SIP-aware or not.
> > bruno>
> > partha> Till now, we are discussing about SIP-aware load balancer
> only.
> > partha> In case the load balancer is SIP-unaware, is it something
> like
> > partha> load-balance by open-loop model wherein there is no feedback
> > required
> > partha> from downstream servers or load balance in the transport
> layer
> > instead
> > partha> of SIP layer ?. Could you please explain your consideration
> in
> > detail.
> > partha>
> > bruno> I was referring to a load balancer at the transport layer=20
> > bruno> with feedback from downstream servers./*
> >
> > Dear Bruno: I envision a SIP-aware load balancer with feedback=20
> > mechanism, where the feedback is carried in SIP signaling.
> >
> > More inline.
> >
> > bruno> Question: Is the Charter intended to cover architectures with
> an
> > in-path
> > bruno> load balancer in front of a farm of SIP servers only or is it
> > expected
> > bruno> to cover as well other architectures where the load balancer
> is
> > off-path
> > bruno> or even architectures where load balancing just relies on
> > frequent
> > bruno> updates of the DNS?
> >
> > My understanding is that service providers are loath to update DNS.
> > As such, a solution that does not depend on DNS is preferable. =20
> > This, then, means that an in-path solution that does not require DNS =

> > would be the most preferred.
> >
> > I note that the LDF function you mention from [1] is a backward=20
> > feedback solution with the LDF updating the DNS periodically.
> >
> > I think that it would be good to have substantive input from the=20
> > service provider community as well as the working group to determine =

> > whether a solution that does not depend on DNS being updated is=20
> > preferred or not.
> >
> > Thoughts?
> >
> > [1] http://www.3gpp.org/ftp/Specs/archive/23_series/23.812/23812-
> > 115.zip
> >
> > Thanks,
> >
> > - vijay
> > --
> > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent=20
> > Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> > Email: vkg@{bell-labs.com,acm.org} / =
vijay.gurbani@alcatel-lucent.com
> > Web:   http://ect.bell-labs.com/who/vkg/
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

From pkyzivat@cisco.com  Thu Jun  9 12:19:08 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4FC11E8213 for ; Thu,  9 Jun 2011 12:19:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.299
X-Spam-Level: 
X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkLTS2L5PWQa for ; Thu,  9 Jun 2011 12:19:02 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 831F211E8125 for ; Thu,  9 Jun 2011 12:19:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3737; q=dns/txt; s=iport; t=1307647142; x=1308856742; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=AkYQcd6rRmfls118FXK8ThoIHqtO2Qf8c8d/6wmKIms=; b=Au4IbwFeUSnmTjz7xM12SBzzrLfTI5ExxxjihYPAEZmP3v2Q46xBRvg7 vxNctAldNl4UscjJxjZAIW8AHpe5YZQ7qQM4NroVu257GcINkTIYYN+bT PoaIzgmen2tImgl4JAUrBHyH7WssxT6jTalI0YNff7vQhMuhL6rQ5zfkm o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah8BAIMc8U2rRDoJ/2dsb2JhbABTl0yOdHeqNJ4PhiMEkSqETYsh
X-IronPort-AV: E=Sophos;i="4.65,342,1304294400"; d="scan'208";a="373695562"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 09 Jun 2011 19:18:53 +0000
Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p59JIrgs008059 for ; Thu, 9 Jun 2011 19:18:53 GMT
Message-ID: <4DF11C9D.9000908@cisco.com>
Date: Thu, 09 Jun 2011 15:18:53 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: dispatch@ietf.org
References: <001801cc26ae$fb0a4120$f11ec360$@us>
In-Reply-To: <001801cc26ae$fb0a4120$f11ec360$@us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dispatch] Request for input. FW: I-D Action:	draft-pfautz-service-provider-identifier-urn-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jun 2011 19:19:08 -0000

I have no agenda wrt this - just questions.

1) why numeric?
2) why fixed length?

I'll observe that fixed-length-numeric + open assignment is asking for 
trouble. Though perhaps it can be mitigated if the numbers must be 
individually assigned through some cumbersome process that can't be 
automated on the requesting end, and if the fixed length is "long enough".

(That doesn't mean I'm opposed to open assignment. I'd be opposed to 
anything more restrictive.)

	Thanks,
	Paul

On 6/9/2011 10:10 AM, Richard Shockey wrote:
> As some of you may have seen from the proposed DISPATCH agenda, this
> document is proposed for discussion. It is in a early draft stage and needs
> comment and community input.
>
> That said I want to strongly support both the concept and the direction this
> draft is taking. It highlights and proposes a solution to an extremely
> important problem in SIP interconnection among global SIP service providers.
> The problem is who do you send the session to if, typically, all you have is
> a E.164 number.
>
> OK some of you would say ..that is what ENUM was supposed to do and
> certainly no one wants listen to me rant on about ENUM anymore, but the
> problem of number translation in SIP service provider networks remains and
> is a serious impediment to global deployments.
>
> There is substantial technical precedent for this type of solution. In the
> North American Numbering Databases there is a Service Provider
> Identification Code (SPID) that has proved very useful for SIP service
> providers in deploying Network to Network Interconnection interfaces. The
> very existence of this identifier has permitted interconnected SIP to expand
> to nearly 30% of the US voice market according to 2010 data from US Federal
> Communications Commission Statistics. This draft proposes to extend this
> technique.
>
> The elegance of this solution is that it does not propose any new protocols,
> nor does it define what type of databases or class of users can use the URN.
>
>
> As the draft points out, this concept has been discussed for some time in
> various industry groups and has been discussed as part of the overall DRINKS
> architecture. It is, IMHO, a "good thing".
>
>
>
> -----Original Message-----
> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]
> On Behalf Of internet-drafts@ietf.org
> Sent: Thursday, June 02, 2011 9:34 AM
> To: i-d-announce@ietf.org
> Subject: I-D Action: draft-pfautz-service-provider-identifier-urn-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> 	Title           : SP URN
> 	Author(s)       : Penn Pfautz
> 	Filename        :
> draft-pfautz-service-provider-identifier-urn-00.txt
> 	Pages           : 5
> 	Date            : 2011-06-02
>
>     This document requests a service provider identifier URN namespace.
>
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-pfautz-service-provider-identifier
> -urn-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-pfautz-service-provider-identifier-
> urn-00.txt
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

From pp3129@att.com  Thu Jun  9 13:22:26 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937E411E80E2 for ; Thu,  9 Jun 2011 13:22:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUZVvTKWNt9A for ; Thu,  9 Jun 2011 13:22:21 -0700 (PDT)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 9D12411E8209 for ; Thu,  9 Jun 2011 13:22:21 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: pp3129@att.com
X-Msg-Ref: server-15.tower-119.messagelabs.com!1307650936!14749789!1
X-StarScan-Version: 6.2.17; banners=-,-,-
X-Originating-IP: [144.160.20.146]
Received: (qmail 31174 invoked from network); 9 Jun 2011 20:22:16 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-15.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jun 2011 20:22:16 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p59KL9aa021740 for ; Thu, 9 Jun 2011 16:21:09 -0400
Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p59KL2ur021639 for ; Thu, 9 Jun 2011 16:21:03 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 9 Jun 2011 16:22:06 -0400
Message-ID: <35FE871E2B085542A35726420E29DA6B06A66225@gaalpa1msgusr7a.ugd.att.com>
In-Reply-To: <4DF11C9D.9000908@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] Request for input. FW: I-DAction:	draft-pfautz-service-provider-identifier-urn-00.txt
Thread-Index: Acwm2iJd8ikaSnG6RImYWvOP3DX6nAAB6OcA
References: <001801cc26ae$fb0a4120$f11ec360$@us> <4DF11C9D.9000908@cisco.com>
From: "PFAUTZ, PENN L (ATTCORP)" 
To: 
Subject: Re: [dispatch] Request for input. FW: I-DAction:	draft-pfautz-service-provider-identifier-urn-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jun 2011 20:22:26 -0000

Responding to Dale and Paul...

Some of the drivers for numeric and fixed length are potential uses in
legacy applications that only use numeric and may want to do things like
(God forbid) prefixing where fixed length would be important.

As to why not oid PENs, the above is part of that but not all. It's not
clear to me what the acceptability of entities obtaining multiple oids
(other than through sub-delegation) although in practice this has
occurred.

That said, I'm not ruling out using oid potentially formatted as a fixed
length string and without the hierarchical appendages.

Penn Pfautz
AT&T Access Management
+1-732-420-4962

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Paul Kyzivat
Sent: Thursday, June 09, 2011 3:19 PM
To: dispatch@ietf.org
Subject: Re: [dispatch] Request for input. FW: I-DAction:
draft-pfautz-service-provider-identifier-urn-00.txt

I have no agenda wrt this - just questions.

1) why numeric?
2) why fixed length?

I'll observe that fixed-length-numeric + open assignment is asking for=20
trouble. Though perhaps it can be mitigated if the numbers must be=20
individually assigned through some cumbersome process that can't be=20
automated on the requesting end, and if the fixed length is "long
enough".

(That doesn't mean I'm opposed to open assignment. I'd be opposed to=20
anything more restrictive.)

	Thanks,
	Paul

On 6/9/2011 10:10 AM, Richard Shockey wrote:
> As some of you may have seen from the proposed DISPATCH agenda, this
> document is proposed for discussion. It is in a early draft stage and
needs
> comment and community input.
>
> That said I want to strongly support both the concept and the
direction this
> draft is taking. It highlights and proposes a solution to an extremely
> important problem in SIP interconnection among global SIP service
providers.
> The problem is who do you send the session to if, typically, all you
have is
> a E.164 number.
>
> OK some of you would say ..that is what ENUM was supposed to do and
> certainly no one wants listen to me rant on about ENUM anymore, but
the
> problem of number translation in SIP service provider networks remains
and
> is a serious impediment to global deployments.
>
> There is substantial technical precedent for this type of solution. In
the
> North American Numbering Databases there is a Service Provider
> Identification Code (SPID) that has proved very useful for SIP service
> providers in deploying Network to Network Interconnection interfaces.
The
> very existence of this identifier has permitted interconnected SIP to
expand
> to nearly 30% of the US voice market according to 2010 data from US
Federal
> Communications Commission Statistics. This draft proposes to extend
this
> technique.
>
> The elegance of this solution is that it does not propose any new
protocols,
> nor does it define what type of databases or class of users can use
the URN.
>
>
> As the draft points out, this concept has been discussed for some time
in
> various industry groups and has been discussed as part of the overall
DRINKS
> architecture. It is, IMHO, a "good thing".
>
>
>
> -----Original Message-----
> From: i-d-announce-bounces@ietf.org
[mailto:i-d-announce-bounces@ietf.org]
> On Behalf Of internet-drafts@ietf.org
> Sent: Thursday, June 02, 2011 9:34 AM
> To: i-d-announce@ietf.org
> Subject: I-D Action:
draft-pfautz-service-provider-identifier-urn-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> 	Title           : SP URN
> 	Author(s)       : Penn Pfautz
> 	Filename        :
> draft-pfautz-service-provider-identifier-urn-00.txt
> 	Pages           : 5
> 	Date            : 2011-06-02
>
>     This document requests a service provider identifier URN
namespace.
>
>
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-pfautz-service-provider-identi
fier
> -urn-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
>
ftp://ftp.ietf.org/internet-drafts/draft-pfautz-service-provider-identif
ier-
> urn-00.txt
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

From dworley@avaya.com  Thu Jun  9 14:48:08 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A875011E811B for ; Thu,  9 Jun 2011 14:48:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.543
X-Spam-Level: 
X-Spam-Status: No, score=-103.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTHY+wz5k7B6 for ; Thu,  9 Jun 2011 14:48:08 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id AD09811E80F5 for ; Thu,  9 Jun 2011 14:48:07 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAEA+8U2HCzI1/2dsb2JhbABTpkB3rTACm0GGIwSWFIsE
X-IronPort-AV: E=Sophos;i="4.65,343,1304308800"; d="scan'208";a="250652773"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Jun 2011 17:48:06 -0400
X-IronPort-AV: E=Sophos;i="4.65,343,1304308800"; d="scan'208";a="661433345"
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 Jun 2011 17:48:05 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 9 Jun 2011 17:48:04 -0400
From: "Worley, Dale R (Dale)" 
To: Paul Kyzivat , "dispatch@ietf.org" 
Date: Thu, 9 Jun 2011 17:45:21 -0400
Thread-Topic: [dispatch] Request for input. FW: I-D	Action: draft-pfautz-service-provider-identifier-urn-00.txt
Thread-Index: Acwm2h/7rG5rRbTNQTyna/QjwOQJFQAFGfQN
Message-ID: 
References: <001801cc26ae$fb0a4120$f11ec360$@us>,<4DF11C9D.9000908@cisco.com>
In-Reply-To: <4DF11C9D.9000908@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dispatch] Request for input. FW: I-D	Action:	draft-pfautz-service-provider-identifier-urn-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jun 2011 21:48:08 -0000

________________________________________
From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Pa=
ul Kyzivat [pkyzivat@cisco.com]

I have no agenda wrt this - just questions.

1) why numeric?
2) why fixed length?

I'll observe that fixed-length-numeric + open assignment is asking for
trouble. Though perhaps it can be mitigated if the numbers must be
individually assigned through some cumbersome process that can't be
automated on the requesting end, and if the fixed length is "long enough".
_______________________________________________

I assume we're going to use Private Enterprise Numbers (http://www.iana.org=
/assignments/enterprise-numbers), since we've already got a registry for th=
at.

Dale

From bruno.chatras@orange-ftgroup.com  Fri Jun 10 00:04:17 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F5211E80D9 for ; Fri, 10 Jun 2011 00:04:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7MxLXkaHP6R for ; Fri, 10 Jun 2011 00:04:10 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id F192C11E8070 for ; Fri, 10 Jun 2011 00:04:08 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2942C8C0003; Fri, 10 Jun 2011 09:03:34 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 1D1068B8004; Fri, 10 Jun 2011 09:03:34 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 10 Jun 2011 09:02:51 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 10 Jun 2011 09:02:50 +0200
Message-ID: <9ECCF01B52E7AB408A7EB8535264214102F29ABE@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] SIP Load balancing (SIPLB) Charter proposal
Thread-Index: AcwlI7mmed+XiSHkQYGxFFc59kn/+QABrDoAADxf01AAIw4MoAADqpCwAAUcWcAAG/XmIA==
References: 	<9ECCF01B52E7AB408A7EB8535264214102E4435E@ftrdmel0.rd.francetelecom.fr>	<9ECCF01B52E7AB408A7EB8535264214102EE636C@ftrdmel0.rd.francetelecom.fr><4DEE3D38.3080106@bell-labs.com>	<9ECCF01B52E7AB408A7EB8535264214102F28BC2@ftrdmel0.rd.francetelecom.fr>	<14C85D6CCBE92743AF33663BF5D24EBA0A43F39F@gaalpa1msgusr7e.ugd.att.com><9ECCF01B52E7AB408A7EB8535264214102F297ED@ftrdmel0.rd.francetelecom.fr> <006d01cc26b7$1140ecc0$33c2c640$@us> 
From: 
To: , , , 
X-OriginalArrivalTime: 10 Jun 2011 07:02:51.0521 (UTC) FILETIME=[69E79F10:01CC273C]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 07:04:17 -0000

I think it's more than just a protocol issue. There are architectural =
aspects here as well (in-path vs. out-path load balancer). I think both =
approaches should be covered.=20

In-path: All SIP traffic goes through the load balancer, which is itself =
a SIP entity=20

Out-Path: SIP entities balance the load themselves, based on information =
received from a load balancer (DNS, 3GPP LDF or something else)

Bruno
=20
> -----Message d'origine-----
> De=A0: Parthasarathi R (partr) [mailto:partr@cisco.com]
> Envoy=E9=A0: jeudi 9 juin 2011 19:45
> =C0=A0: Richard Shockey; CHATRAS Bruno RD-CORE-ISS; md3135@att.com;
> vkg@bell-labs.com
> Cc=A0: dispatch@ietf.org
> Objet=A0: RE: [dispatch] SIP Load balancing (SIPLB) Charter proposal
>=20
> Bruno,
>=20
> Thanks for your information about DNS based SIP load balancing in 3GPP
> spec (in different mail thread).
>=20
> IMO, There are two parts in feedback based SIP load balancing
>=20
> 1) Feedback value
> 2) Feedback protocol choice (SIP, DNS, SNMP)
>=20
> The current mail thread is about feedback protocol which has to be =
used.
> I agree with you that it is possible for other protocols for SIP load
> balancing. We will add the consideration and discuss in detail about
> protocol choice to sort out the discussion.
>=20
>=20
> I really didn't see the usage of DNS based load balancing mechanism in
> Enterprise deployment. But initially, I have explored to use SNMP to
> pass feedback value as a trap and I got the comments that SIP based
> feedback mechanism will reduce the dependency on another protocol =
stack
> in the system. I guess that the comment will apply for DNS as well and
> also FQDN in SIP URI is not mandatory in SIP.
>=20
> Thanks
> Partha
>=20
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Richard Shockey
> Sent: Thursday, June 09, 2011 8:38 PM
> To: bruno.chatras@orange-ftgroup.com; md3135@att.com; =
vkg@bell-labs.com
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
>=20
>=20
> Humm .. an application specific use of DNS technology in a closed
> controlled environment.  I heard of these kind of things before.
> Sounds like a interesting idea. :-)
>=20
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of bruno.chatras@orange-ftgroup.com
> Sent: Thursday, June 09, 2011 9:28 AM
> To: md3135@att.com; vkg@bell-labs.com
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
>=20
> Hi Martin,
> The load balancing capability can be implemented on dedicated DNS
> servers only. This does not put the service provider's DNS
> infrastructure at risk.
> Bruno
>=20
>=20
> > -----Message d'origine-----
> > De=A0: DOLLY, MARTIN C (ATTSI) [mailto:md3135@att.com] Envoy=E9=A0:
> mercredi
> > 8 juin 2011 22:39 =C0=A0: CHATRAS Bruno RD-CORE-ISS; =
vkg@bell-labs.com
> Cc
> > : dispatch@ietf.org Objet=A0: RE: [dispatch] SIP Load balancing =
(SIPLB)
> > Charter proposal
> >
> > Bruno,
> >
> > Do we really want to impact the DNS with a load balancing capability
> > linked to overload control?
> >
> > Martin
> >
> > -----Original Message-----
> > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] =
On
> > Behalf Of bruno.chatras@orange-ftgroup.com
> > Sent: Tuesday, June 07, 2011 11:54 AM
> > To: vkg@bell-labs.com
> > Cc: dispatch@ietf.org
> > Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
> >
> > Vijay,
> >
> > Speaking as a representative of a Service Provider, I can tell you
> > that we are interested in DNS-based solutions. I believe that the WG
> > should address both types of solutions.
> >
> > Bruno
> >
> > > -----Message d'origine-----
> > > De=A0: Vijay K. Gurbani [mailto:vkg@bell-labs.com] Envoy=E9=A0: =
mardi 7
> > > juin 2011 17:01 =C0=A0: CHATRAS Bruno RD-CORE-ISS Cc=A0: =
partr@cisco.com;
> > > dispatch@ietf.org Objet=A0: Re: [dispatch] SIP Load balancing =
(SIPLB)
> > > Charter proposal
> > >
> > > On 06/07/2011 04:13 AM, bruno.chatras@orange-ftgroup.com wrote:
> > > bruno> Comment: In the list of considerations that must be taken
> > > bruno> into
> > > account I
> > > bruno> would add =AB Whether the load balancer is SIP-aware or =
not.
> > > bruno>
> > > partha> Till now, we are discussing about SIP-aware load balancer
> > only.
> > > partha> In case the load balancer is SIP-unaware, is it something
> > like
> > > partha> load-balance by open-loop model wherein there is no
> feedback
> > > required
> > > partha> from downstream servers or load balance in the transport
> > layer
> > > instead
> > > partha> of SIP layer ?. Could you please explain your =
consideration
> > in
> > > detail.
> > > partha>
> > > bruno> I was referring to a load balancer at the transport layer
> > > bruno> with feedback from downstream servers./*
> > >
> > > Dear Bruno: I envision a SIP-aware load balancer with feedback
> > > mechanism, where the feedback is carried in SIP signaling.
> > >
> > > More inline.
> > >
> > > bruno> Question: Is the Charter intended to cover architectures
> with
> > an
> > > in-path
> > > bruno> load balancer in front of a farm of SIP servers only or is
> it
> > > expected
> > > bruno> to cover as well other architectures where the load =
balancer
> > is
> > > off-path
> > > bruno> or even architectures where load balancing just relies on
> > > frequent
> > > bruno> updates of the DNS?
> > >
> > > My understanding is that service providers are loath to update =
DNS.
> > > As such, a solution that does not depend on DNS is preferable.
> > > This, then, means that an in-path solution that does not require
> DNS
> > > would be the most preferred.
> > >
> > > I note that the LDF function you mention from [1] is a backward
> > > feedback solution with the LDF updating the DNS periodically.
> > >
> > > I think that it would be good to have substantive input from the
> > > service provider community as well as the working group to
> determine
> > > whether a solution that does not depend on DNS being updated is
> > > preferred or not.
> > >
> > > Thoughts?
> > >
> > > [1] http://www.3gpp.org/ftp/Specs/archive/23_series/23.812/23812-
> > > 115.zip
> > >
> > > Thanks,
> > >
> > > - vijay
> > > --
> > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent
> > > Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> > > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-
> lucent.com
> > > Web:   http://ect.bell-labs.com/who/vkg/
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From md3135@att.com  Fri Jun 10 04:34:44 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C369A11E8083 for ; Fri, 10 Jun 2011 04:34:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.52
X-Spam-Level: 
X-Spam-Status: No, score=-106.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNQ3s-YBqO2J for ; Fri, 10 Jun 2011 04:34:40 -0700 (PDT)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7A22A11E807E for ; Fri, 10 Jun 2011 04:34:40 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: md3135@att.com
X-Msg-Ref: server-12.tower-120.messagelabs.com!1307705679!22099239!1
X-StarScan-Version: 6.2.17; banners=-,-,-
X-Originating-IP: [144.160.20.146]
Received: (qmail 2976 invoked from network); 10 Jun 2011 11:34:39 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-12.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Jun 2011 11:34:39 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p5ABXWhU006380; Fri, 10 Jun 2011 07:33:32 -0400
Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p5ABXS08006317; Fri, 10 Jun 2011 07:33:28 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 10 Jun 2011 07:34:33 -0400
Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA0A4A2FF0@gaalpa1msgusr7e.ugd.att.com>
In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102F29ABE@ftrdmel0.rd.francetelecom.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] SIP Load balancing (SIPLB) Charter proposal
Thread-Index: AcwlI7mmed+XiSHkQYGxFFc59kn/+QABrDoAADxf01AAIw4MoAADqpCwAAUcWcAAG/XmIAAJujqQ
References: 	<9ECCF01B52E7AB408A7EB8535264214102E4435E@ftrdmel0.rd.francetelecom.fr>	<9ECCF01B52E7AB408A7EB8535264214102EE636C@ftrdmel0.rd.francetelecom.fr><4DEE3D38.3080106@bell-labs.com>	<9ECCF01B52E7AB408A7EB8535264214102F28BC2@ftrdmel0.rd.francetelecom.fr>	<14C85D6CCBE92743AF33663BF5D24EBA0A43F39F@gaalpa1msgusr7e.ugd.att.com><9ECCF01B52E7AB408A7EB8535264214102F297ED@ftrdmel0.rd.francetelecom.fr> <006d01cc26b7$1140ecc0$33c2c640$@us>  <9ECCF01B52E7AB408A7EB8535264214102F29ABE@ftrdmel0.rd.francetelecom.fr>
From: "DOLLY, MARTIN C (ATTSI)" 
To: , , , 
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 11:34:44 -0000

AT&T supports the approach in the current draft, and would view the "DNS =
approach" as an option.
Let DNS do what it does well, and donot over complicate it.

-----Original Message-----
From: bruno.chatras@orange-ftgroup.com =
[mailto:bruno.chatras@orange-ftgroup.com]=20
Sent: Friday, June 10, 2011 3:03 AM
To: partr@cisco.com; richard@shockey.us; DOLLY, MARTIN C (ATTSI); =
vkg@bell-labs.com
Cc: dispatch@ietf.org
Subject: RE: [dispatch] SIP Load balancing (SIPLB) Charter proposal

I think it's more than just a protocol issue. There are architectural =
aspects here as well (in-path vs. out-path load balancer). I think both =
approaches should be covered.=20

In-path: All SIP traffic goes through the load balancer, which is itself =
a SIP entity=20

Out-Path: SIP entities balance the load themselves, based on information =
received from a load balancer (DNS, 3GPP LDF or something else)

Bruno
=20
> -----Message d'origine-----
> De=A0: Parthasarathi R (partr) [mailto:partr@cisco.com]
> Envoy=E9=A0: jeudi 9 juin 2011 19:45
> =C0=A0: Richard Shockey; CHATRAS Bruno RD-CORE-ISS; md3135@att.com;
> vkg@bell-labs.com
> Cc=A0: dispatch@ietf.org
> Objet=A0: RE: [dispatch] SIP Load balancing (SIPLB) Charter proposal
>=20
> Bruno,
>=20
> Thanks for your information about DNS based SIP load balancing in 3GPP
> spec (in different mail thread).
>=20
> IMO, There are two parts in feedback based SIP load balancing
>=20
> 1) Feedback value
> 2) Feedback protocol choice (SIP, DNS, SNMP)
>=20
> The current mail thread is about feedback protocol which has to be =
used.
> I agree with you that it is possible for other protocols for SIP load
> balancing. We will add the consideration and discuss in detail about
> protocol choice to sort out the discussion.
>=20
>=20
> I really didn't see the usage of DNS based load balancing mechanism in
> Enterprise deployment. But initially, I have explored to use SNMP to
> pass feedback value as a trap and I got the comments that SIP based
> feedback mechanism will reduce the dependency on another protocol =
stack
> in the system. I guess that the comment will apply for DNS as well and
> also FQDN in SIP URI is not mandatory in SIP.
>=20
> Thanks
> Partha
>=20
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Richard Shockey
> Sent: Thursday, June 09, 2011 8:38 PM
> To: bruno.chatras@orange-ftgroup.com; md3135@att.com; =
vkg@bell-labs.com
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
>=20
>=20
> Humm .. an application specific use of DNS technology in a closed
> controlled environment.  I heard of these kind of things before.
> Sounds like a interesting idea. :-)
>=20
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of bruno.chatras@orange-ftgroup.com
> Sent: Thursday, June 09, 2011 9:28 AM
> To: md3135@att.com; vkg@bell-labs.com
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
>=20
> Hi Martin,
> The load balancing capability can be implemented on dedicated DNS
> servers only. This does not put the service provider's DNS
> infrastructure at risk.
> Bruno
>=20
>=20
> > -----Message d'origine-----
> > De=A0: DOLLY, MARTIN C (ATTSI) [mailto:md3135@att.com] Envoy=E9=A0:
> mercredi
> > 8 juin 2011 22:39 =C0=A0: CHATRAS Bruno RD-CORE-ISS; =
vkg@bell-labs.com
> Cc
> > : dispatch@ietf.org Objet=A0: RE: [dispatch] SIP Load balancing =
(SIPLB)
> > Charter proposal
> >
> > Bruno,
> >
> > Do we really want to impact the DNS with a load balancing capability
> > linked to overload control?
> >
> > Martin
> >
> > -----Original Message-----
> > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] =
On
> > Behalf Of bruno.chatras@orange-ftgroup.com
> > Sent: Tuesday, June 07, 2011 11:54 AM
> > To: vkg@bell-labs.com
> > Cc: dispatch@ietf.org
> > Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
> >
> > Vijay,
> >
> > Speaking as a representative of a Service Provider, I can tell you
> > that we are interested in DNS-based solutions. I believe that the WG
> > should address both types of solutions.
> >
> > Bruno
> >
> > > -----Message d'origine-----
> > > De=A0: Vijay K. Gurbani [mailto:vkg@bell-labs.com] Envoy=E9=A0: =
mardi 7
> > > juin 2011 17:01 =C0=A0: CHATRAS Bruno RD-CORE-ISS Cc=A0: =
partr@cisco.com;
> > > dispatch@ietf.org Objet=A0: Re: [dispatch] SIP Load balancing =
(SIPLB)
> > > Charter proposal
> > >
> > > On 06/07/2011 04:13 AM, bruno.chatras@orange-ftgroup.com wrote:
> > > bruno> Comment: In the list of considerations that must be taken
> > > bruno> into
> > > account I
> > > bruno> would add =AB Whether the load balancer is SIP-aware or =
not.
> > > bruno>
> > > partha> Till now, we are discussing about SIP-aware load balancer
> > only.
> > > partha> In case the load balancer is SIP-unaware, is it something
> > like
> > > partha> load-balance by open-loop model wherein there is no
> feedback
> > > required
> > > partha> from downstream servers or load balance in the transport
> > layer
> > > instead
> > > partha> of SIP layer ?. Could you please explain your =
consideration
> > in
> > > detail.
> > > partha>
> > > bruno> I was referring to a load balancer at the transport layer
> > > bruno> with feedback from downstream servers./*
> > >
> > > Dear Bruno: I envision a SIP-aware load balancer with feedback
> > > mechanism, where the feedback is carried in SIP signaling.
> > >
> > > More inline.
> > >
> > > bruno> Question: Is the Charter intended to cover architectures
> with
> > an
> > > in-path
> > > bruno> load balancer in front of a farm of SIP servers only or is
> it
> > > expected
> > > bruno> to cover as well other architectures where the load =
balancer
> > is
> > > off-path
> > > bruno> or even architectures where load balancing just relies on
> > > frequent
> > > bruno> updates of the DNS?
> > >
> > > My understanding is that service providers are loath to update =
DNS.
> > > As such, a solution that does not depend on DNS is preferable.
> > > This, then, means that an in-path solution that does not require
> DNS
> > > would be the most preferred.
> > >
> > > I note that the LDF function you mention from [1] is a backward
> > > feedback solution with the LDF updating the DNS periodically.
> > >
> > > I think that it would be good to have substantive input from the
> > > service provider community as well as the working group to
> determine
> > > whether a solution that does not depend on DNS being updated is
> > > preferred or not.
> > >
> > > Thoughts?
> > >
> > > [1] http://www.3gpp.org/ftp/Specs/archive/23_series/23.812/23812-
> > > 115.zip
> > >
> > > Thanks,
> > >
> > > - vijay
> > > --
> > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent
> > > Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> > > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-
> lucent.com
> > > Web:   http://ect.bell-labs.com/who/vkg/
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From guyingjie@huawei.com  Sun Jun 12 23:55:36 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBE221F8498; Sun, 12 Jun 2011 23:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.737
X-Spam-Level: 
X-Spam-Status: No, score=-100.737 tagged_above=-999 required=5 tests=[AWL=-1.861, BAYES_50=0.001, CN_BODY_35=0.339, CN_BODY_509=0.029, CN_BODY_832=0.004, HTML_MESSAGE=0.001, MANGLED_GRNTEE=2.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79j4s0stvGhs; Sun, 12 Jun 2011 23:55:33 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id B5FEB21F8495; Sun, 12 Jun 2011 23:55:31 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMP006YOV7LOB@szxga04-in.huawei.com>; Mon, 13 Jun 2011 14:54:58 +0800 (CST)
Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTP id <0LMP00DWQV7LSV@szxga04-in.huawei.com>; Mon, 13 Jun 2011 14:54:57 +0800 (CST)
Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 13 Jun 2011 14:54:54 +0800
Received: from g00107907 (10.138.41.104) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 13 Jun 2011 14:54:53 +0800
Date: Mon, 13 Jun 2011 14:56:41 +0800
From: "Yingjie Gu(yingjie)" 
X-Originating-IP: [10.138.41.104]
To: tsvwg@ietf.org, dispatch@ietf.org
Message-id: <003e01cc2997$0cb96960$262c3c20$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/mixed; boundary="Boundary_(ID_syjEGnl9pB2WJrEh/zMbQg)"
Content-language: zh-cn
Thread-index: AcwplwweZ120wpp3QcmuTCIlEcs5Ng==
Cc: wangdanhua@huawei.com, 'Fan Yongbing' , rbonica@juniper.net
Subject: [dispatch] Looking forward to your comments: Virtual machine/host migraiton in Data Center.
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Jun 2011 06:55:36 -0000

--Boundary_(ID_syjEGnl9pB2WJrEh/zMbQg)
Content-type: multipart/related; boundary="Boundary_(ID_/1PbB/2x1jdhEcFsLazVqQ)"


--Boundary_(ID_/1PbB/2x1jdhEcFsLazVqQ)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_Q7wk6KaGRFUGzdMb7/+t7w)"


--Boundary_(ID_Q7wk6KaGRFUGzdMb7/+t7w)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable

Hi all,

We have sent a draft regarding virtual machine/host migration in Data =
Center
to OPSAWG. I guess people in TSV Area may also be interested in this
problem. Please review the attached draft for detail.=20

Virtualization enables Data Center to improve their resource utility to =
70%
or higher. Virtual machine migration enables even better resource =
utility
and better flexibility. A physical server is virtualized into several
virtual machines/hosts and the virtual machines can be migrate to any
location within the pre-designated area in the Data Center, or to a
different Data Center site, based on physical server status, network
conditions, application requirements or subscribers=A1=AF requirements. =
For
example, a part of network is experiencing badly packet loss. In order =
to
guarantee high priority services, the virtual machine hosting high =
priority
services are migrated to a place with better network performance.

Two parts of information need to be considered when migrate a virtual
machine: 1) software resource, such as OS and memory, on server side, =
and 2)
policies and dynamic information on network side. This draft is focus on =
2).
Since the most important feature of Virtual machine migration is that =
the
running service should not be significantly interrupted, it=A1=AFs quite
challenging on how to migrate the policies and dynamic information on
network side, within or between Data Center sites.=20

=20

Anyone who has any questions or comments, please post to the this =
thread.
The authors looks forward to your feedback.=20

=20

Best Regards

Yingjie Gu

=20

  _____ =20

Gu Yingjie
=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologies =
Co., Ltd.
Company_logo

Phone:=20
Fax:=20
Mobile:=20
Email:=20
=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=CC=EF=BB=AA=CE=
=AA=BB=F9=B5=D8 =D3=CA=B1=E0=A3=BA518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com=20

  _____ =20

=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=
=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=
=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA
=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3=
=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=
=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=
=CA
=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=
=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=
=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attachments contain confidential information from
HUAWEI, which=20
is intended only for the person or entity whose address is listed above. =
Any
use of the=20
information contained herein in any way (including, but not limited to,
total or partial=20
disclosure, reproduction, or dissemination) by persons other than the
intended=20
recipient(s) is prohibited. If you receive this e-mail in error, please
notify the sender by=20
phone or email immediately and delete it!


--Boundary_(ID_Q7wk6KaGRFUGzdMb7/+t7w)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: quoted-printable


Hi=
 all,
We=
 have sent a draft regarding virtual machine/host migration in Data =
Center to OPSAWG. I guess people in TSV Area may also be interested in =
this problem. Please review the attached draft for detail. =

Vi=
rtualization enables Data Center to improve their resource utility to =
70% or higher. Virtual machine migration enables even better resource =
utility and better flexibility. A physical server is virtualized into =
several virtual machines/hosts and the virtual machines can be migrate =
to any location within the pre-designated area in the Data Center, or to =
a different Data Center site, based on physical server status, network =
conditions, application requirements or subscribers=A1=AF requirements. =
For example, a part of network is experiencing badly packet loss. In =
order to guarantee high priority services, the virtual machine hosting =
high priority services are migrated to a place with better network =
performance.
Tw=
o parts of information need to be considered when migrate a virtual =
machine: 1) software resource, such as OS and memory, on server side, =
and 2) policies and dynamic information on network side. This draft is =
focus on 2). Since the most important feature of Virtual machine =
migration is that the running service should not be significantly =
interrupted, it=A1=AFs quite challenging on how to migrate the policies =
and dynamic information on network side, within or between Data Center =
sites. 
 
An=
yone who has any questions or comments, please post to the this thread. =
The authors looks forward to your feedback. 
 
Be=
st Regards
Yi=
ngjie Gu
 
Gu Yingjie
=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE =
Huawei Technologies Co., Ltd.
3D"Company_logo"

Phone: 
Fax: 
Mobile: 
Email: 
=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=CC=EF=BB=AA=
=CE=AA=BB=F9=B5=D8 =D3=CA=B1=E0=A3=BA518129
Huawei =
Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, =
P.R.China
http://www.huawei.com =

=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=
=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=
=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=
=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=
=CE=D0=CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=
=B2=BF=BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=
=A2=B7=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=
=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=
=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=
=FE=A3=A1
Thi=
s e-mail and its attachments contain confidential information from =
HUAWEI, which 
is intended only for the person or entity whose =
address is listed above. Any use of the 
information contained herein =
in any way (including, but not limited to, total or partial =

disclosure, reproduction, or dissemination) by persons other than =
the intended 
recipient(s) is prohibited. If you receive this e-mail =
in error, please notify the sender by 
phone or email immediately and =
delete it!
=

--Boundary_(ID_Q7wk6KaGRFUGzdMb7/+t7w)--

--Boundary_(ID_/1PbB/2x1jdhEcFsLazVqQ)
Content-id: 
Content-type: image/jpeg; name=image001.jpg
Content-transfer-encoding: base64
Content-disposition: attachment; filename=image001.jpg

/9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA
AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA
AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA
AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB
AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A
AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA////////
/////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD/////////
////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA
AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A
AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB
AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA
AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA
AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg
AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS
AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF
U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA
AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA
TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA
AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA
AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB
bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA
AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl
QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u
ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN
BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA
AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM
QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT
ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O
Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB
IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB
AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR
obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF
tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR
AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV
NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA
AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6
6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs
VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns
U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9
w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh
fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX
146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh
SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t
bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo
JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb
qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv
/QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F
ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4
HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v
6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m
+u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6
tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ
JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r
WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z
OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB
AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA
AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq
AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8
CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox
ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA
BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB
AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf
Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM
DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM
DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED
EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA
AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV
UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0
pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB
UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz
hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/
APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3
0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl
/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP
UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+
qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW
9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq
FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp
VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku
cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf
Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0
PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C
OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us
XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j
QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6
jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n
0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT
gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf
UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj
Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI
BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04
MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA
AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh
CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp
anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV
1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK
C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy
0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD
hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm
5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge
ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn
yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr
aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g
dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf
03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l
6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo
9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai
uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45
RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV
zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc
TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM
v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S
reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8
V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM
qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/
thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le
LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x
ke3tRX0lRQB//9k=

--Boundary_(ID_/1PbB/2x1jdhEcFsLazVqQ)--

--Boundary_(ID_syjEGnl9pB2WJrEh/zMbQg)
Content-type: text/plain; name=draft-gu-opsa-policy-migration-00.TXT
Content-transfer-encoding: 7BIT
Content-disposition: attachment; filename=draft-gu-opsa-policy-migration-00.TXT




Network Working Group                                              Y. Gu
Internet-Draft                                                    Huawei
Intended status: Standards Track                                  Y. Fan
Expires: December 10, 2011                                 China Telecom
                                                            June 8, 2011


            Policies and dynamic information migration in DC
                   draft-gu-opsa-policy-migration-00

Abstract

   Virtualization and Virtual Machine (VM) migration provide Data Center
   with feasibility and improves the utilization of limited physical
   resource, e.g. switches/routers, servers and links.  Meanwhile, a
   variety of policies (e.g.  ACL, firewalls, load balancers, IPS and
   QoS) are deployed in Data Center to improve system security and
   gurantee SLA.  Those polices are executed by rules configured or
   generated on network devices.  E.g. packet filtering policies are
   executed by Access Control List on switches or firewalls.  Another
   example is Load balancer (LB) who extablishes TCP/HTTP connections
   with external clients and balances connections among server farm.
   During this process, TCP connection tables are dynamically generated
   on LB.  When VM migrates, the network devices that processing and
   forward VM's packets may change.  In order to keep VM's running
   serives and guanrantee security on new place, VM-relevant policies,
   including static policies as well as the dynamically generated
   information, need to migrate with VM.

   This draft describes some examples of the policies that need to
   migrate with VM, the problems that need to consider when migrate
   polices in Data Center.  The goal is to justify that it is necessary
   for IETF to make new effort on management of virtualized Data Center.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."



Gu & Fan                Expires December 10, 2011               [Page 1]

Internet-Draft  policy and dynamic information migration       June 2011


   This Internet-Draft will expire on December 10, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



































Gu & Fan                Expires December 10, 2011               [Page 2]

Internet-Draft  policy and dynamic information migration       June 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminologies and concepts . . . . . . . . . . . . . . . . . .  5
   3.  Policies Classification  . . . . . . . . . . . . . . . . . . .  6
     3.1.  Static Policies  . . . . . . . . . . . . . . . . . . . . .  7
       3.1.1.  Use Cases  . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Dynamic Information  . . . . . . . . . . . . . . . . . . .  9
       3.2.1.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . 10
   4.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     4.1.  Policy migration within a single site  . . . . . . . . . . 22
     4.2.  Polices migration in asymmetric architecture . . . . . . . 23
     4.3.  Policies migration between DC sites  . . . . . . . . . . . 24
   5.  General Considerations . . . . . . . . . . . . . . . . . . . . 25
     5.1.  Time-sensitive . . . . . . . . . . . . . . . . . . . . . . 26
     5.2.  Notification . . . . . . . . . . . . . . . . . . . . . . . 27
     5.3.  Functionality  . . . . . . . . . . . . . . . . . . . . . . 27
     5.4.  Resource Capability  . . . . . . . . . . . . . . . . . . . 29
     5.5.  Migration Feedback . . . . . . . . . . . . . . . . . . . . 29
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 29
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     8.1.  Normative Reference  . . . . . . . . . . . . . . . . . . . 29
     8.2.  Informative Reference  . . . . . . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30


























Gu & Fan                Expires December 10, 2011               [Page 3]

Internet-Draft  policy and dynamic information migration       June 2011


1.  Introduction

   Data centers can host tens or even thousands of different
   applications.  Some are simple applications such as web servers
   providing static content, while some may be very complex, e.g.
   e-commerce, that requiring all around privacy protection and data
   security.  Clients of Data Center, unlike server hosting clients,
   raise more strict QoS and Security requirements.

   To satisfy different level of security requirements and to manage and
   improve the performance of these applications, data centers typically
   deploy a large variety of policies on network devices, e.g. interface
   security functions on switches and routers, and middleboxes,
   including firewalls, load balancers, SSL offloaders, web caches and
   intrusion prevention boxes.

   To satisfy QoS requirements, Data Center also implement QoS mechanism
   as ISP network.  IEEE 802.1 DCB working group defines a series of
   standards to guarantee quality of service.

      802.1Qau - Congestion Notification

      802.1Qaz - Enhanced Transmission Selection

      802.1Qbb - Priority-based Flow Control

   Without regard to mobile network, the existing DC network management
   has a pre-assumption that end hosts will not move.  If an end host
   moves, because the physical link has to break down and the service
   also has to break down, the network can treat it as two separated
   parts: one host leave the network and another host join the network.

   Server Virtualization and Virtual Machine Migration changes the
   situation and disable the preassumption.  With server virtualization,
   providers can reduce networking cost.  To support the same volume of
   services, fewer network devices, servers and links are required than
   before.  Multiple Virtual Machines (VMs) are established within a
   single physical server and the VMs are allowed to relocate to a
   different servers within the same subnet of Data Center, or even
   among different sites of a Data Center.  This is so called VM
   Migration.  VM Migration brings flexibility to Data Center, meanwhile
   it makes network management more complex and challenging.

   Unlike servers power off and power on again, in which case, servers
   know and can bear services disruption, VM Migration requires that
   VM's IP Address shouldn't change and running service mustn't be
   disrupted.  Meawhile, security level should be guaranteed.  In order
   to satisfy the above requirements, the VM relevant polices need to



Gu & Fan                Expires December 10, 2011               [Page 4]

Internet-Draft  policy and dynamic information migration       June 2011


   migrate with VM.

   IEEE 802.1Qbg has developed VSI Discovery and Configuration Protocol
   (VDP) to enable ajacent bridge to discover VM and configure
   corresponding static polices.

   The author has presented the problem to IEEE 802.1 DCB task group.
   DCB has recognized this problem and make extension to VDP to notify
   VM status, which will be introduced in Section 5.2.  IEEE 802.1 DCB
   would like to know furture progress of this problem in IETF and ask
   the author to let know the furthur progress.

   In the following sections, detail examples and senarios are given to
   explain why and which polices need to migrate with VM.


2.  Terminologies and concepts

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Source Network Device, Source switch, or Source device: the network
   device/switch/device from where the VM migrates.  I.E. VM is
   originally located under the source network device/switch/device.

   Destination Network Device, Destination switch, or Destination
   device: the network device/switch/device to where the VM migrates.
   I.E. VM is relocated to the destination network device/switch/device.

   TCP connection table: A table containing TCP connection-specific
   information.

   VM: Virtual Machine; A completely isolated operation system which is
   installed by software on a normal operation system.  An normal
   operation system can be virtualized into several VM.

   ACL: Access Control List; A list of rules that specifies which
   packets can be permited, which should be denied.

   QoS: Quality of Service;

   FW: Firewall; a policy based security function, typically used for
   restricting access to/from specific devices and applications.

   LB: Load Balancer; A methodology to distribute workload across
   multiple computers or a computer cluster, network links, central
   processing units, disk drives, or other resources, to achieve optimal



Gu & Fan                Expires December 10, 2011               [Page 5]

Internet-Draft  policy and dynamic information migration       June 2011


   resource utilization, maximize throughput, minimize response time,
   and avoid overload.

   NAT: Network Address Translation.  Refer to RFC3303.


3.  Policies Classification

   In this section, we use the following figure  as an example
   network architecture.  Some redundant links are omitted for
   simplicity. the new VM1 under Server4 represents the VM1 after
   migration.  VM1 and new VM1 don't exist at the same time.  In the
   real world, the networking of DC could be different.
              -------------------------------------------------
              |                     Gateway                   |
              -------------------------------------------------
                    /    \                 /       \
                   /      \               /         \
    -----   --------     --------     --------     --------    ------
    |FW-A|--| AGG1  |----| AGG2  |    | AGG3  |----| AGG4  |---|FW-B|
    -----   --------     --------     --------     --------    ------
            |     |     |     |        |      |    |     |
            |     \     /     |        |      \    /     |
            |      \   /      |        |       \  /      |
            |       \/        |        |        \/       |
            |       /\        |        |        /\       |
            |      /  \       |        |       /  \      |
            |     /    \      |        |      /    \     |
            |    |      |     |        |     |     |     |
           ----------   ----------     ----------   ----------
           |Switch1 |   |Switch2 |     |Switch3 |   |Switch4 |
           ----------   ----------     ----------   ----------
           |       \   /      |        |       \  /      |
           |        \/        |        |        \/       |
           |        /\        |        |        /\       |
           |       /  \       |        |       /  \      |
         ----------   ----------      ----------   ----------
         |Server1 |   |Server2 |      |Server3 |   |Server4 |
         ----------   ----------      ----------   ----------
          |      |                                  |     |
         VM1    VM2                               VM3    new VM1

         Figure 1: Basic networking for discussion in this draft.

   One key feature of VM migration is that VM's IP Address shouldn't
   change, otherwise the running service could be disrupted.  In order
   to achieve this, additional mechanism need to be developed.  However,
   these mechanism are out of the scope of this draft.  In policy



Gu & Fan                Expires December 10, 2011               [Page 6]

Internet-Draft  policy and dynamic information migration       June 2011


   migration problem statement, we assume that there already exist an
   effective mechanism to guarantee VM's IP Address unchanged.

   Two kinds of polices are introduced in this draft, i.e. static
   polices and dynamic polices (or dynamic information).

3.1.  Static Policies

   Administrators of DC establish VM profile, which may include static
   policies for the VM, e.g.  VLAN Name, bandwidth indication, and Qos
   parameters, etc.  And they are suppposed to be consistent during the
   lifetime of the VM.  No matter where VM migrates, the static policies
   need to move with VM for the sake of security, privacy and QoS.

   Static polices can be described by natural languages or mathematics
   fomula.  They are implementated by specific configurations on
   different network elements, e.g. a ACL item on physical ports of
   switches enables a packet filtering policies.  In this draft, we
   discuss the migration of policies, but the policies migration also
   implies the migration of configurations on network devices, because
   configurations are embodiment of policies.

   Policies that need to migrate with VM are those can influence VM's
   running services or are related to security and billing&accounting.
   Different network devices will contain different kind of policies.
   For example, it can be static Access Control Lists on Access
   switches, QoS on switches and routers, security rules on Firewalls,
   and load balancing mechanism on Load Balancer, etc.

3.1.1.  Use Cases

   It's hard to enumerate all the VM-related static polices.  In this
   section, we just give two examples of static policies to show the
   necessity of static polices migration.

3.1.1.1.  Access Control List

    shows the influence of lack of ACLs on destination switch.
   There is an Default ACL on source switch (Switch1) deny all packets
   from IP subnet 10.138.3.0 to Internet.  And another ACL 101 allows IP
   Address 10.138.3.1, VM1's IP Address, to send packets to Internet.
   VM1 has a running service on it.  During service provisioning, VM1 is
   migrated to Server4 under Switch4, Where there is default ACL to deny
   all packets.  Since ACL 101 on Switch1 is not migrated to Switch4,
   VM1's IP Address falls into a default ACL which deny all unmatching
   packets.  As a result, packets belonging to the running services are
   dropped, hence the running service is disrupted.




Gu & Fan                Expires December 10, 2011               [Page 7]

Internet-Draft  policy and dynamic information migration       June 2011


            -------------------------------------------------
            |                     Gateway                   |
            -------------------------------------------------
                 //\   \                     /       \
                / *     \                   /         \
 ------     --------     --------     --------     --------    ------
 |FW-A|----| AGG1  |----| AGG2  |     | AGG3  |----| AGG4  |---|FW-B|
 ------     --------     --------     --------     --------    ------
            |*     |     |     |      |      |    |     |
            |*     \     /     |      |      \    /     |
            |*      \   /      |      |       \  /      |
            |*       \/        |      |        \/       |
ACL 101:    |*       /\        |      |        /\       |
permit VM1  |*      /  \       |      |       /  \      |Default ACL:
Default ACL:|*     /    \      |      |      /    \     |deny all
deny all    |*    |     |      |      |     |      |    |Packets dropped
           ----------   ----------  ----------  ----------
           |Switch1 |   |Switch2 |  |Switch3 |  |Switch4 |
           ----------   ----------  ----------  ----------
            |*      \   /      |      |       \  /      |/\  \/
            |*       \/        |      |        \/       |*   /\
            |*       /\        |      |        /\       |*
            |*      /  \       |      |       /  \      |*
           ----------   ----------   ----------   ----------
           |Server1 |   |Server2 |   |Server3 |   |Server4 |
           ----------   ----------   ----------   ----------
            |*    |                                 |   |*
            |*    |                                 |   |*
           VM1    VM2                              VM3  new VM1

               Figure 2: VM migration without ACL migration

3.1.1.2.  VLAN

   VMs with similar properties could be grouped into a VLAN, e.g. end
   hosts providing Web service are grouped into Web-VLAN.  Each VLAN has
   a unique VLAN ID.  Only when a VM is configured into a specific VLAN,
   can it receives broadcast packets from other VMs in the same VLAN.

   In , VM1 belongs to VLAN1.  Assuming VLAN1 is not configured on
   the port on AGG4 that attaching Switch4, and VM1 migrates to new VM1,
   Broadcast pakcets from another VM belonging to VLAN1 are forwarded to
   AGG4, however they can not be forwarded to Switch4, since broadcast
   packets are sending only to VLAN1-enabled port.  The *** line
   represents VLAN1 broadcast, which can not access Server4.  New VM1
   can not receive VLAN1 broadcast.





Gu & Fan                Expires December 10, 2011               [Page 8]

Internet-Draft  policy and dynamic information migration       June 2011


                   -----------------------------------
                   |              Gateway            |
                   -----------------------------------
                                    |
                                    |
               ------------------------------------------
               |             Core Switch                |
               ------------------------------------------
                    /*     \            /       *\
                   /*       \          /        \/\
    ------    -------    -------    --------   -------   ------
    |FW-A|----|AGG1 |----| AGG2|    | AGG3  |--| AGG4|---|Fw-B|
    ------    -------    -------    --------   -------   ------
              |*   *|    |  |        |    |    |    | \/ No VLAN1
              |*   *\    /  |        |    \    /    | /\
              |*    *\  /   |        |     \  /     |
              |*     *\/    |        |      \/      |
              |*     /*\    |        |      /\      |
              |*    / * \   |        |     /  \     |
              |*   /   * \  |        |    /    \    |
              |*  |    * |  |        |   |      |   |
            ---------  ---------    ---------   ----------
            |Switch1|  |Switch2|    |Switch3|   |Switch4 |
            ---------  ---------    ---------   ----------
   VLAN1     |*    \  /   * |VLAN1   |     \  /     |
             |*     \/    * |        |      \/      |
             |*     /\    * |        |      /\      |
             |*    /  \  \/ |        |     /  \     |
            ---------  ---------    ---------  ----------
            |Server1|  |Server2|    |Server3|  |Server4 |
            ---------  ---------    ---------  ----------
             |*   |                             |   |
             |\/  |                             |   |
            VM1   VM2                         VM3  new VM1

               Figure 3: VM migration without VLAN migration

3.2.  Dynamic Information

   Except for the static policies, some dynamic information could also
   be generated by network devices to assist packet processing.  TCP
   connection table on proxy is an obvious example.  Proxy intervenes
   the direct connection between external client and internal server,
   which can protect internal server from attacking.  Proxy establishes
   TCP connection with external client for internal server, a TCP
   connection Table being generated on proxy.  Then proxy establishes
   TCP connection with internal server for external client, another TCP
   connection table being generated.  These TCP Connection table can not



Gu & Fan                Expires December 10, 2011               [Page 9]

Internet-Draft  policy and dynamic information migration       June 2011


   be configured by network manager, but is generated by network
   devices, e.g.  Firewalls and proxies, according to real connections.
   Another example is cumulative data, e.g. how many packets/TCP
   connecition requests an end host has sent.  This information can only
   be generated by network devices according to real traffic.
   Configurations could be generated dynamically by network devices
   themselves according to the dynamic informaiton, e.g.  Dynamic ACLs.

   In following section, we enumerate several kinds of dynamic
   information.  A dynamic information could be generated on different
   network devices, meanwhile a specific network devices could hold more
   than one kind of dynamic information.  In following section, we
   introduce possible dynamic informaiton on specific network devices.

3.2.1.  Use Cases

3.2.1.1.  Switches

   We use switch to represent Top of Racks, Bridges and switches.  These
   devices have slightly different definition and functions, and may be
   used or combinedly used in differenct scenarios.

3.2.1.1.1.  Dynamic ACL

   In , assuming a default ACL is configured on Switch1 that all
   traffic is denied unless the end host is authorized and
   authenticated.  VM1 has been authenticated on source device and a
   dynamic ACL has been generated which allows VM1's traffic to pass
   through.

   A 'Deny all' default ACL is configured on Switch4 too.  VM1 migrates
   to destination device which attaches to Swtich4.  Because Switch4
   regards new VM1 as an unathenticated end host, according to default
   ACL, all data packets from VM1 will be dropped.  In order to continue
   service, VM1 has to authenticate again.  In this case, running
   service is disrupted.  If authentication and dynamic ACL, generated
   on Switch1, can be migrated to Switch4, data packets from VM1 are
   permitted, hence, without regard to influence caused by features,
   running service can continue.












Gu & Fan                Expires December 10, 2011              [Page 10]

Internet-Draft  policy and dynamic information migration       June 2011


              -------------------------------------------------
              |                     Gateway                   |
              -------------------------------------------------
                     //\   \              /       \
                    / *     \            /         \
    ------      -------   -------     -------     ------   ------
    |FW-A|-----| AGG1 |---| AGG2 |    | AGG3|----| AGG4|---|FW-B|
    ------      -------   -------     -------     ------   ------
                |*   |     |   |       |     |    |  |
                |*   \     /   |       |     \    /  |
                |*    \   /    |       |      \  /   |
                |*     \/      |       |       \/    |
                |*     /\      |       |       /\    |
                |*    /  \     |       |      /  \   |
                |*   /    \    |       |     /    \  |
                |*  |     |    |       |    |     |  |
   Default ACL: ---------  ---------  ---------  --------- Default ACL:
   deny all     |Switch1|  |Switch2|  |Switch3|  |Switch4| deny all
                ---------  ---------  ---------  ---------
                 |*   \   /    |      |     \  /   /\| \/  VM1's pakcets
   Dynamic ACL:  |*    \/      |      |      \/     *| /\  are dropped.
   Permit VM!    |*    /\      |      |      /\     *|
                 |*   /  \     |      |     /  \    *|
               ---------  ---------  ---------  ---------
               |Server1|  |Server2|  |Server3|  |Server4|
               ---------  ---------  ---------  ---------
                |*   |                          |   *|
                |*   |                          |   *|
               VM1   VM2                       VM3    new VM1

           Figure 4: VM migration without dynamic ACL migration

3.2.1.1.2.  DHCP snooping

   Assuming Switch1 is DHCP Snooping Enabled and a DHCP Snooping mapping
   item is created for VM1: (IP-VM1: MAC-VM1).  This mapping is created
   dynamically by listening to DHCP Response message.  If VM1 migrate to
   destination device, since the IP Address of VM1 doesn't change, there
   is no DHCP Request sent by VM1 before lease time expires.  So on
   Switch4, no mapping information can be generated by listening to DHCP
   response, and all traffic from VM1 will be dropped.

   If DHCP snooping table on Switch1 can be migrated to Switch4, Switch4
   learns from the migrated DHCP snooping talbe that packet with IP-VM1
   and MAC-VM1 can be regularly forwarded.






Gu & Fan                Expires December 10, 2011              [Page 11]

Internet-Draft  policy and dynamic information migration       June 2011


           -------------------------------------------------
           |                     Gateway                   |
           -------------------------------------------------
                  //\   \               /     \
                 / *     \             /       \
    ------   -------     ------   --------   -------   ------
    |FW-A|---|AGG1 |----| AGG2|   | AGG3 |---|AGG4 |---|FW-B|
    ------   --------    ------   --------   -------   ------
              |*  |     |  |       |   |    |   |
   DHCP       |*  \     /  |       |   \    /   |
   Response   |*   \   /   |       |    \  /    |
       \      |*    \/     |       |     \/     |
        \     |*    /\     |       |     /\     |
         \    |*   /  \    |       |    /  \    |DHCP snooping enabled
          \   |*  /    \   |       |   /    \   |No DHCP request
   DHCP      >|* |     |   |       |   |    |   |from new VM1
   snooping ---------  ---------  ---------  ----------
   enabled  |Switch1|  |Switch2|  |Switch3|  |Switch4 |
            ---------  ---------  ---------  ----------
   ---------- |*   \   /  |       |     \  /   /\| \/ VM1's packets
   |Snooping| |*    \/    |       |      \/     *| /\ are dropped
   |Table   | |*    /\    |       |      /\     *|
   ---------- |*   /  \   |       |     /  \    *|
            --------  --------- ---------  ----------
           |Server1| |Server2|  |Server3|  |Server4 |
            --------  --------- ---------  ----------
              |*  |                         |   *|
              |*  |                         |   *|
             VM1  VM2                     VM3  new VM1

       Figure 5: VM migration without DHCP snooping table migration

3.2.1.1.3.  IGMP snooping

   IGMP snooping is similar to DHCP Snooping.  Multicast membership is
   created on ports by listening to IGMP JOIN or membership report
   messages.  When a switch receives a multicast packet, it forwards the
   packet to the port which has joined the multicast group.  In ,
   assuming VM1 sends an IGMP JOIN Group1 message to Multicast server,
   port1 and port-uplink on Switch1 check the JOIN message and tag on
   port1 and port-uplink that they should forward Multicast packets from
   Group1.  If VM1 migrates to destination, since migration is
   transparent to VM, VM1 will not send IGMP membership report until
   next IGMP General Query is received.  If port2 on Swtich4 didn't join
   Group1, multicast packet from Group1 won't be forward to port2, then
   VM1 won't be able to receive Multicast packets.





Gu & Fan                Expires December 10, 2011              [Page 12]

Internet-Draft  policy and dynamic information migration       June 2011


            -------------------------------------------------
            |                     Gateway                   |
            -------------------------------------------------
                   /*    \                   /       *\
                  /*      \                 /         *\
  ------      --------     --------      --------    --------     ------
  |FW-A|-----| AGG1  |----| AGG2  |      | AGG3  |---| AGG4  |--- |FW-B|
  ------      --------     --------      --------    --------     ------
              |*     |     |     |       |      |    |    *|
   IGMP       |*     \     /     |       |      \    /    *|
 JOIN Snooping|*      \   /      |       |       \  /     *|
       \      |*       \/        |       |        \/      *|
        \     |*       /\        |       |        /\      *|
         \    |*      /  \       |       |       /  \     *|IGMP enabled
          \   |*     /    \      |       |      /    \    *|No IGMP JOIN
             >|*    |     |      |       |     |     |   \/|from new VM1
 IGMP         ----------   ----------   ----------   ----------   \/
 enabled      |Switch1 |   |Switch2 |   |Switch3 |   |Switch4 |   /\
              ----------   ----------   ----------   ----------
              |*      \   /      |       |       \  /      |
 ----------   |*       \/        |       |        \/       |
 |Group1: |   |*       /\        |       |        /\       |
 |Port1   |   |*      /  \       |       |       /  \      |
 ----------   ----------   ---------    ---------   ----------
              |Server1 |   |Server2|    |Server3|   |Server4 |
              ----------   ---------    ---------   ----------
              |*    |                                 |    |
              |\/   |                                 |    |
             VM1    VM2                             VM3    new VM1

       Figure 6: VM migration without IGMP snooping table migration

3.2.1.1.4.  Cumulative Data

   To ensure VMs consume no more than assigned bandwidth and to enable
   QoS control, billing and accounting, bridges need to cumulate packets
   number and calculate packet rate.  Lack of these cumulative data and
   statistic data on destination bridge decrease the accuracy.

3.2.1.2.  Firewall

   Fireall (FW) is a filtering device that separates LAN segments,
   giving each segment a different security level and establishing a
   security perimeter that controls the traffic flow between segments.
   There are different types of firewalls based on their packet-
   processing capabilities and their awareness of application-level
   information:




Gu & Fan                Expires December 10, 2011              [Page 13]

Internet-Draft  policy and dynamic information migration       June 2011


      Packet-filetering firewalls

      Proxy firewalls

      Stateful firewalls

      Hybrid firewalls

3.2.1.2.1.  Dynamic ACL

   Packet filtering Firewall filters packet according to ACL.  Dynamic
   ACL could be generated to protect internal network/servers from
   attacks, similar to dynamic ACL on Switches.

3.2.1.2.2.  TCP Connection Table

   Proxy Firewall proxies TCP connections between internal servers and
   external clients.  It establishes TCP connection with external client
   and then it establishes TCP connection with internal server.  TCP
   connection tables are cached on Proxy Firewall to indicate how to
   transform following packets belonging to this TCP connection.
       External Client        Firewall          Internal server
           |----- TCP SYN  ----->|
           |<-----SYN/ACK  ------|
           |-------ACK     ----->|
                                 |--------TCP SYN ------>|
                                 |<-------SYN/ACK -------|
                                 |--------ACK     ------>|
           |-------DATA   ------>|--------DATA    ------>|
           |<------DATA   -------|<-------DATA    -------|

                         Figure 7: Proxy Firewall



















Gu & Fan                Expires December 10, 2011              [Page 14]

Internet-Draft  policy and dynamic information migration       June 2011


                 -------------------------------------------------
                 |                     Gateway                   |
                 -------------------------------------------------
  ----------------     /*  \                  /    *\
  |TCP Conn Table|    /*    \                /      *\ No corresponding
  ----------------   /*      \              /        *\ TCP Conn Table
  ------ **** --------     --------     --------    -------- ****>------
  |FW-A|-----| AGG1  |----| AGG2  |     | AGG3 |----| AGG4 |----- |FW-B|
  ------ **** --------     --------     --------    --------  \/  ------
              |*     |     |     |       |      |    |     |  /\
              |*     \     /     |       |      \    /     |
              |*      \   /      |       |       \  /      |
              |*       \/        |       |        \/       |
              |*       /\        |       |        /\       |
              |*      /  \       |       |       /  \      |
              |*     /    \      |       |      /    \     |
              |*    |     |      |       |     |     |     |
             ----------   ----------    ----------   ----------
             |Switch1 |   |Switch2 |    |Switch3 |   |Switch4 |
             ----------   ----------    ----------   ----------
             |*      \   /      |       |       \  /       |
             |*       \/        |       |        \/        |
             |*       /\        |       |        /\        |
             |*      /  \       |       |       /  \       |
           ----------   ----------    ----------   ----------
           |Server1 |   |Server2 |    |Server3 |   |Server4 |
           ----------   ----------    ----------   ----------
             |*    |                                |      |
             |\/   |                                |      |
            VM1    VM2                             VM3    new VM1

       Figure 8: VM migration without TCP connection table migration

   A typical TCP Connection Table includes the following data:

      tcpConnState: The state of this TCP connection.

      tcpConnLocalAddress: The local IP address for this TCP connection.

      tcpConnLocalPort: The local port number for this TCP connection.

      tcpConnRemAddress: The remote IP address for this TCP connection.

      tcpConnRemPort: The remote port number for this TCP connection.

   A TCP Connectin Table could also includes the following information:





Gu & Fan                Expires December 10, 2011              [Page 15]

Internet-Draft  policy and dynamic information migration       June 2011


      Sequence Number: the sequence number in the packet header the
      sender is going to send.

      Acknowledgement Number: the sequence number in the packet header
      the receiver is hoping to receive.

      Idle time: the time that the tcp connection table hasn't been
      updated.

   Assuming TCP Connection Table item is generated for VM1 on Fw-A, the
   information is as follows:

      tcpConnState == Established

      tcpConnLocalAddress == 10.138.3.1

      tcpConnLocalPort == 1234

      tcpConnRemAddress: == 192.167.22.3

      tcpConnRemPort == 4321

   VM1 migrates to Server4 under Switch4, without TCP Connection Table
   items migration.  The packets belonging to this TCP Connection will
   continue coming, which will pass FW-B, instead of FW-A.  Because
   there is no TCP Connection Table for VM1 on FW-B, the following
   packets belonging to the TCP Connection will be dropped, hence the
   running service is broken down.

3.2.1.2.3.  Cumulative Data

   One example for cumulative data is unfinished TCP Connection
   established by a specific VM.  In order to avoid TCP SYN flood,
   Firewall may control the unfinished TCP Connection established by a
   single end host by setting a threshold.  For example, the NM set the
   threshold to 50, and VM1 has established 30 unfinished TCP
   connections.  If the cumulated TCP connection number isn't migrated
   to destination devices, the destination device will allow VM1 to
   establish up to 50 unfinished TCP connections.  For the single
   destination device, the unfinished TCP connections established by VM1
   is under control, but for the whole DC, VM1 has established 80
   unfinished TCP connections.  So VM1 has consume more resoureces than
   allowed.

3.2.1.2.4.  NAT Address Mapping

   Data center may implement network address translation.  Sometimes NAT
   function is enabled on Firewall.  Private IP Add. is assigned to



Gu & Fan                Expires December 10, 2011              [Page 16]

Internet-Draft  policy and dynamic information migration       June 2011


   internal VM.  When VM communicate with external client, NAT function
   assigns a public IP Add. to the communicating internal VM.  A mapping
   between private IP Add. and public IP Add. is recorded on NAT
   function.

   Assuming a mapping from Pri-IP-VM1 to Pub-IP-VM1 is generated on
   FW-A.  When VM1 migrates to Server4 without the address mapping,
   following packets from external client can not be translated to
   correct Pri-IP-VM1, and vice versa.
                  -------------------------------------------------
                  |                     Gateway                   |
                  -------------------------------------------------
                        //\   \              / \*  Dst: Pub-IP-VM1
     Src: Pub-IP-VM1   /*      \            /   \*  No Address mapping
  -----------------   /*        \          /     \* from Pub-IP-VM1
  |Address Mapping|  /*          \        /       \* to Private-IP-VM1
  ----------------- /*            \      /         \*Packets are dropped
   ------- ****>--------    --------   -------     ------- ****>------
   |NAT-A|------| AGG1  |---| AGG2  |  |AGG3 |----| AGG4 |-----|NAT-B|
   ------- <****--------    --------   -------     -------\/   -------
                |*     |     |    |     |    |    |     | /\
                |*     \     /    |     |    \    /     |
                |*      \   /     |     |     \  /      |
                |*       \/       |     |      \/       |
                |*       /\       |     |      /\       |
                |*      /  \      |     |     /  \      |
                |*     /    \     |     |    /    \     |
                |*    |     |     |     |   |     |     |
               ---------   ---------   ---------  ----------
               |Switch1|   |Switch2|   |Switch3|  |Switch4 |
               ---------   ---------   ---------  ----------
               |*      \   /      |     |      \  /     |
  Src:         |*       \/        |     |       \/      |
  Pri-IP-VM1   |*       /\        |     |       /\      |
               |*      /  \       |     |      /  \     |
              ---------   ---------    ---------  ----------
              |Server1|   |Server2|    |Server3|  |Server4 |
              ---------   ---------    ---------  ----------
               |*     |                            |    |
               |\/    |                            |    |
              VM1    VM2                          VM3  new VM1

       Figure 9: VM migration without NAT Address Mapping migration








Gu & Fan                Expires December 10, 2011              [Page 17]

Internet-Draft  policy and dynamic information migration       June 2011


3.2.1.3.  Load Balancer

   When a cluster of servers are organized to provide same services,
   Load Balancer (LB) is used to balance service load between servers.
   All external requests are sent to LB, before they are redirected to a
   specific server.  First, external clients extablish TCP connection
   with LB.  Then LB decides which specific server should take care of
   the requests.  Two ways to redirect the requests, i.e. transparent LB
   and proxy LB.  The following dynamic information applies for both
   ways.

3.2.1.3.1.  Connection Table

   Layer 4 LB identifies and makes load-balancing decesion by Layer 4
   Protocol, e.g.  TCP.  Layer 4 LB generates TCP connection table which
   is similar to TCP connection table on Firewall.  
       External Client        Load Balancer         Internal server
           | ------- TCP SYN  ------->|-------TCP SYN ----->|
           |<--------SYN/ACK  --------|<------SYN/ACK ------|
           |---------ACK      ------->|-------ACK     ----->|
           |---------HTTP REQ ------->|-------HTTP REQ----->|
           |<--------HTTP ACK --------|<------HTTP ACK------|
           |---------DATA     ------->|-------DATA    ----->|
           |<--------DATA     --------|<------DATA    ------|

                     Figure 10: Layer 4 Load Balancing

   Layer 5 LB identifies and makes load-balancing decesion by Layer 5
   protocol, e.g.  HTTP, SMTP and FTP, that is found in packet payload.
   The Layer 5 information could be HTTP URL, HTTP cookie, or HTTP
   header field user agent.  Layer 5 LB generates connection table for
   HTTP, SMTP, and FTP, etc.
       External Client        Load Balancer          Internal server
           | ------- TCP SYN  ----->|
           |<--------SYN/ACK  ------|
           |---------ACK      ----->|
           |---------HTTP Req ----->|
                                    |-------TCP SYN ----->|
                                    |<------SYN/ACK ------|
                                    |-------ACK     ----->|
                                    |-------HTTP Req----->|
           |---------HTTP ACK ----->|-------HTTP ACK----->|
           |---------DATA     ----->|-------DATA    ----->|
           |<--------DATA     ------|<------DATA    ------|

                     Figure 11: Layer 5 Load Balancing

    shows the result of lack of Connection table on destination



Gu & Fan                Expires December 10, 2011              [Page 18]

Internet-Draft  policy and dynamic information migration       June 2011


   LB.
         -------------------------------------------------
         |                     Gateway                   |
         -------------------------------------------------
-------------     /*  \                 /    *\ No VM1's Conn Table
|Conn Table |    /*    \               /      *\Packets could be dropped
-------------   /*      \             /        *\or mis-redirected
------ <**** -------    --------     -------   ------- ****>-------
|LB-A|------| AGG1 |---| AGG2  |     | AGG3|---|AGG4 |----- |LB-B|
------ ****> -------    --------     -------   ------- <**** ------
            |*     |     |     |     |     |    |   |*
            |*     \     /     |     |     \    /   |*
            |*      \   /      |     |      \  /    |*
            |*       \/        |     |       \/     |*
            |*       /\        |     |       /\     |*
            |*      /  \       |     |      /  \    |*
            |*     /    \      |     |     /    \   |*
            |*    |     |      |     |    |     |   |*
          ----------   ----------   ---------   ---------
          |Switch1 |   |Switch2 |   |Switch3|   |Switch4|
          ----------   ----------   ---------   ---------
           |*      \   /      |      |       \  /    |*
           |*       \/        |      |        \/     |*
           |*       /\        |      |        /\     |*
           |*      /  \       |      |       /  \    |*
          ----------   ----------   ----------   ----------
          |Server1 |   |Server2 |   |Server3 |   |Server4 |
          ----------   ----------   ----------   ----------
           |*   |                                |*  |
           |\/  |                                |\/ |
          VM1  VM2                              VM3  new VM1


        Figure 12: VM migration without Connection table migration

3.2.1.3.2.  Sticky Table

   Session persistence refers to the capability of the Load alancer to
   logically group multiple connections from the same client transaction
   to the service.  Session persistence is also known as stickiness or
   sticky connections because the goal is to stick two or more
   connections together as part of a single session.  This grouping is
   done to ensure the connections are handled and forwarded to the
   groups of servers that are aware of and expect to see the remaining
   connections.  This ensures that the client has a successful
   interaction with the application.

   LB usually keeps a sticky table for session persistence, which is



Gu & Fan                Expires December 10, 2011              [Page 19]

Internet-Draft  policy and dynamic information migration       June 2011


   used to match incoming requests to existing connections so that they
   can be grouped together.  A sticky table could include the following
   information.

      Sticky groups

         Group name (sticky group identifier)

         Type (sticky group type, according to stick methods)

         Sticky server farm

         Backup server farm

         Aggregate state (to indicate whether the state of the backup
         server is tied to the virtual server state)

         Sticky enabled on backup server farm (to indicate whether the
         backup server farm is sticky)

         Replicate (to indicate whether to replicate sticky entries on
         the standby device)

         Timeout (a mechanism to age out sticky table entries)

         Timeout active connections (to specify whether to time out
         sticky table entries if active connections exists after the
         sticky timer expires)

      Sticky methods

      Sticky connections

      Real servers

   In , two connections, represented by * line and $ line, are
   redirected to VM1, and a sticky table is generated on LB-A.  VM1
   migrates to new VM1, without Sticky table migrates with VM1.  A new
   connection, represented by & line, arriving at LB-B, which can not
   know that this connection should be redirected to new VM1, because of
   lack of sticky table.  As a result, LB-B redirect the new connection
   to other VM than new VM1.  This mis-redirection could cause key
   information lost.  For example, in e-business, refer to








Gu & Fan                Expires December 10, 2011              [Page 20]

Internet-Draft  policy and dynamic information migration       June 2011


                            External Client-X
                                 * $ &
                                 * $ &
                                 * $ &
              --------------------------------------------
              |                 Gateway                  |
              --------------------------------------------
                    /*$ \             /\*$&
                   /*$   \           /  \*$& No Sticky table for client-X
-------------     /*$     \         /    \*$& Connections from client-X
|Sticky Table|   /*$       \       /      \*$& may be redirected to
-------------   /*$         \     /        \*$& different servers
 ----- <*$*$*-------    ------   -------    -------- *$&*> ------
|LB-A|------| AGG1 |----| AGG2|  | AGG3|----| AGG4  |----- |LB-B|
 ----- *$*$> -------    ------   -------    --------<*$&*  ------
             |*$   |     |    |     |  |    |     |*$&
             |*$   \     /    |     |  \    /     |*$&
             |*$    \   /     |     |   \  /      |*$&
             |*$     \/       |     |    \/       |*$&
             |*$     /\       |     |    /\       |*$&
             |*$    /  \      |     |   /  \      |*$&
             |*$   /    \     |     |  /    \     |*$&
             |*$  |      |    |     | |      |    |*$&
           ---------   --------   ---------  ----------
           |Switch1|   |Switch2|  |Switch3|  |Switch4 |
           ---------   --------   ---------  ----------
            |*$    \  /       |     |    \  /     |*$&
            |*$     \/        |     |     \/      |*$&
            |*$     /\        |     |     / \     |*$&
            |*$    /  \       |     |    /   \    |*$&
         ----------   ----------  ---------  ----------
         |Server1 |   |Server2 |  |Server3|  |Server4 |
         ----------   ----------  ---------  ----------
           |$%   |                            |&  |*$
           |\/   |                            |\/ |\/
          VM1    VM2                         VM3  new VM1
******
$$$$$$   Threee connectons from the same external clients.
&&&&&&

          Figure 13: VM migration without Sticky table migration

   While server or server farm move to a new location under a new LB, in
   order to keep the existing connections and sessions, as well as
   session persistence, both connection table and sticky table need to
   move with servers.





Gu & Fan                Expires December 10, 2011              [Page 21]

Internet-Draft  policy and dynamic information migration       June 2011


4.  Scenarios

   In previous section, we introduce two classes of policies, i.e.
   static policies and dynamic information.  The introduction is based
   on a simplized networking architecture and intentionally omit other
   factors.  The polices in the example network implies <1:1> partner,
   that is polices need to move from one device to another.  However, in
   real world, network architectures are much complicate than the
   simplized example networking.  We introduce several scenarios in this
   section.  Different architecture raise different requirements and
   migration partner style.

4.1.  Policy migration within a single site

   A DC site means a geographic location, which could include one
   subnet, or several subnets.  A VM migrates to a new location which is
   in the same subnet as original location.  In this case, there might
   not be policies on Middleboxes that need to be migrated, since new
   VM1 is under the same Middleboxes as VM1.  But dynamic information on
   switches need to migrate as well.































Gu & Fan                Expires December 10, 2011              [Page 22]

Internet-Draft  policy and dynamic information migration       June 2011


             -------------------------------------------------
             |                     Gateway                   |
             -------------------------------------------------
               /     \                     /       \
              /       \                   /         \
 ------   --------     --------       --------     --------       ------
 |FW-A|---| AGG1  |----| AGG2  |      | AGG3  |----| AGG4  |----- |FW-B|
 ------   --------     --------       --------     --------       ------
          |      |     |     |        |      |    |     |
          |      \     /     |        |      \    /     |
          |       \   /      |        |       \  /      |
          |        \/        |        |        \/       |
          |        /\        |        |        /\       |
          |       /  \       |        |       /  \      |
          |      /    \      |        |      /    \     |
          |     |     |      |        |     |     |     |
         ----------   ----------     ----------   ----------
         |Switch1 |   |Switch2 |     |Switch3 |   |Switch4 |
         ----------   ----------     ----------   ----------
          |       \   /      |        |       \  /      |
          |        \/        |        |        \/       |
          |        /\        |        |        /\       |
          |       /  \       |        |       /  \      |
        ----------   ----------     ----------   ----------
        |Server1 |   |Server2 |     |Server3 |   |Server4 |
        ----------   ----------     ----------   ----------
            |            |
          VM1           new VM1

        Figure 14: Policy migration within a single DataCenter site

4.2.  Polices migration in asymmetric architecture

   The network architecture could be asymmetric.  Refer to Fig16.  In
   this case, there is possible to encounter <1:n> or  partnership.
   The former partnership implies policies on one orginal device might
   need to migrate to n destination devices.  The latter partnership
   implies policies on multiple original devices might need to migrate
   to one destination devices.  For example, when VM1 migrate from
   Server 4 to Server1, the dynamic information on both Switch4 and ToR
   need to migrate to Switch1, which is 2:1 partnership。










Gu & Fan                Expires December 10, 2011              [Page 23]

Internet-Draft  policy and dynamic information migration       June 2011


           -------------------------------------------------
           |                     Gateway                   |
           -------------------------------------------------
                 /     \                  /       \
                /       \                /         \
   ------   -------     -------      --------     --------    ------
   |FW-A|---| AGG1|----| AGG2 |      | AGG3  |----| AGG4  |---|FW-B|
   ------   -------     -------      --------     --------    ------
             |    |     |     |       |      \   /      |
             |    \     /     |       |        \/       |
             |     \   /      |       |        /\       |
             |      \/        |      ----------   ----------
             |      /\        |      |Switch3 |   |Switch4 |
             |     /  \       |      ----------   ----------
             |    /    \      |       |       \  /      |
             |    |     |     |       |        \/       |
            ---------   ----------    |        /\       |
            |Switch1|   |Switch2 |   ----------   ----------
            ---------   ----------   |   ToR  |   |  ToR   |
             |       \  /     |      ----------   ----------
             |        \/      |       |        \/       |
             |        /\      |       |        /\       |
             |       /  \     |       |       /  \      |
            ----------   ---------   ----------   ----------
            |Server1 |   |Server2|   |Server3 |   |Server4 |
            ----------   ---------   ----------   ----------
                |                                       |
              new VM1                                  VM1

          Figure 15: Polices migration in asymmetric architecture

4.3.  Policies migration between DC sites

   Currently, most VM hot migration is limited in the same data center
   site.  But in the furture there might be requirements for VM
   migration between data center sites, as shown in .  A use case
   for this scenario is resource coordination between data center sites.
   A DC provier has two data center sites in different countries, and
   both of them serve external clients with similar applications.  Some
   of the applications are high priority applications, others are normal
   priority ones.  At first, requests from external clients are
   redirected to the data center site which are physically close to the
   external clients.  However, at some time, one data center is
   approaching its capability limits, which could be servers capability
   limits (i.e. few server capability are available for new requests) or
   network capability limits (i.e. network can not support so much
   packet processing requirement, and packet loss happens) and
   performance is degraded.  In order to guarantee high priority



Gu & Fan                Expires December 10, 2011              [Page 24]

Internet-Draft  policy and dynamic information migration       June 2011


   applications, and try best to make fewest damage to normal priority
   applications, some VMs, who provide normal priority applications, can
   be migrated to the other data center sites.

   In this case, policies on switches, middleboxes and gateways need to
   migrate to new devices on the other data center site.

   Policies migration between data centers also need to consider the
   asymmetric structure.
          ------------------          ---------------------
          |    Gateway     |          |     Gateway2      |
          ------------------          ---------------------
                /     \                     /       \
               /       \                   /         \
  ------   --------     --------       --------     --------      ------
  |FW-A|---| AGG1  |----| AGG2  |      | AGG3  |----| AGG4  |-----|FW-B|
  ------   --------     --------       --------     --------      ------
           |      |     |     |        |      |    |     |
           |      \     /     |        |      \    /     |
           |       \   /      |        |       \  /      |
           |        \/        |        |        \/       |
           |        /\        |        |        /\       |
           |       /  \       |        |       /  \      |
           |      /    \      |        |      /    \     |
           |     |     |      |        |     |     |     |
          ----------   ----------     ----------   ----------
          |Switch1 |   |Switch2 |     |Switch3 |   |Switch4 |
          ----------   ----------     ----------   ----------
           |       \   /      |        |       \  /      |
           |        \/        |        |        \/       |
           |        /\        |        |        /\       |
           |       /  \       |        |       /  \      |
         ----------   ----------     ----------   ----------
         |Server1 |   |Server2 |     |Server3 |   |Server4 |
         ----------   ----------     ----------   ----------
             |                                         |
           VM1                                       new VM1

               Figure 16: Polices migration between DC sites


5.  General Considerations

   In this section, we enumerate some general considerations on Policy
   migration.  Only with deep consideration on these factors can we
   achieve a successful VM migration and policy migration.





Gu & Fan                Expires December 10, 2011              [Page 25]

Internet-Draft  policy and dynamic information migration       June 2011


5.1.  Time-sensitive

   VM migration needs a period to finish memory and register copy.
   Fig.3 shows the VMware VMotion process.  There are three points we
   should pay attention to.

      Pre-copy period: VM begins to prepare for migration.  In this
      period, VM pre-copy memory state to the new VM on destination
      device.  The original VM is still power on and service is still
      running, which means the memory and register could keep changing.
      The new VM is power-on.

      VM not running period: The end phase of memory copy.  In this
      period, original VM stop running service, the memory will not
      change.  Original VM finish copying the rest changed memory and
      register to new VM.  New VM is still power-on.

      VM power-off point: After original VM receives the OK message from
      new VM, it turns off the power, and meanwhile the new memory
      starts to run.

   We can see that it's unrealistic to make a 'zero delay' VM migration,
   because there is at least about 1 second period (VM not running
   period) when neither VM is running.

   Assuming there is a 3rd-party device can GET and SET dynamic
   information.(This is only an possible way to migrate polices.
   Polices could also be migrated distributedly.  The author has no
   preferrence to any approaches in this draft.)  The 3rd-party device
   GET dynamic information at Time A, and finish SET at Time B. At Time
   A, the Sequence Number of VM1's TCP Connection is 99.  After 3rd-
   party device GET dynamic information, VM1's TCP connection keeps
   transferring packets and Sequence Number increase to 110, until VM
   not running period begins.  During VM not running period, no TCP
   packet is acknowledged by VM1, so the Sequence Number is 110.  At
   Time B, the destination Firewall is SET by Sequence Number 99.  When
   new VM1 starts, the packets belonging to VM1's TCP connection comes
   to Firewall-B with Sequence Number 111.  Since the receiving Sequence
   Number doesn't equal to the Acknowleadge Sequence Number of
   Firewall-B, this packet will be dropped and the running service is
   broken down.

   Another example: After Time A, VM1 may establish new TCP connections,
   which are not migrated to new Firewall, then following packets
   belonging to new TCP connections will be dropped and running services
   are disrupted.





Gu & Fan                Expires December 10, 2011              [Page 26]

Internet-Draft  policy and dynamic information migration       June 2011


 -------------------------------------------------------
    ^     ||    |   Power-on destination VM          ^
    |     ||    |                                    |
    |     ||--->| ---------------------------     VMotion
   VM     ||    |    Pre-copy memory state        abortable
  running ||--->|                                   |-------->Time A
 on source||    |                                   | /\
    |     ||--->|                                   |Dynamic Information
    |     ||--->|                                   |keep changing
    V     ||    |                                   | \/
 ---------------------------------------------------|-----------
    ^     |---->| Checkpoint-save src VM and        |
    |     |---->| transfer state                    |
    |     |     |-----------------------------------|
   VM not |---->| transfer remaining changed memory |-------->Time B
  running |     | and checkpoint-restore dst VM     V
    |     |     |--------------------------------------
  ~1sec   |<----| send restore OK
    V     |     |
 ------------------------------------------------------
          |    ||  Power-off source VM
          |    ||  VM running on destination

                     Figure 17: VMware VMotion process

5.2.  Notification

   As Section 5.1shows, policy migration is very sensitive to migration
   time.  Either later or earlier may cause service disruption.  The
   best migration time is after the original VM stops running and before
   the destination VM begins running.  Only Hypervisor knows the acurate
   VM status.  So we need a notification from server side, Hypervisor in
   specific, to tell network side when to migrate polices.

   In fact, the author has presented the problem to IEEE 802.1 DCB task
   group, which defines VSI Discovery and Configuration protocols (VDP).
   DCB has recognized this problem and make effort within its scope.
   DCB has extended VDP, in 802.1 Qbg, to enable notification from
   Hypervisor to adjacent bridge.  DCB expects corresponding IETF WG to
   make furthur effort to distribute the notification to devices from
   Layer 3 to Layer 7.  And IEEE 802.1 DCB working group would like to
   see further progress at IETF on this problem.

5.3.  Functionality

   Data center architecture could be heterogeneous, both in physical
   structure and functionality.  Section 4.2 and  shows the
   asymmetric physical structure.  The following figure shows the case



Gu & Fan                Expires December 10, 2011              [Page 27]

Internet-Draft  policy and dynamic information migration       June 2011


   where functionality on devices is heterogenous.  While VM migrates
   from one location to a heterogeneous location, it's necessary to
   negotiate and make sure that essential functions are supported at
   destination location.  Otherwise, VM migration maybe fail.  Even VM
   successfully migrates, there might be security risk and/or service
   failure.  VM Managers who want to migrate VM between heterogeneous
   architecutre must be aware of the risk.

    shows two examples of functionality heterogeneous.  FW-A is
   the source Firewall with packet filtering function, and a dynamic ACL
   is generated on FW-A for VM1.  FW-B is the destination Firewall
   without packet filtering funtion.  In this case, dynamic ACL on FW-A
   can not be implemented on FW-B.  The similar case happens on Switch1
   and Switch4.  Switch1 has DHCP snooping function enabled, while
   Switch has not.  DHCP snooping table from Switch1 can not be
   implemented on Switch4.
             -------------------------------------------------
             |                     Gateway                   |
             -------------------------------------------------
                /     \                     /       \
               /       \                   /         \
 ------    --------     --------       ------    -------   ------
 |FW-A|----| AGG1 |----| AGG2  |      | AGG3|----| AGG4|---|FW-B|
 ------    --------     --------       ------    -------   ------
 with      |      |     |     |        |    |    |    | without
 Packet    |      \     /     |        |    \    /    | Packet filtering
 filtering |       \   /      |        |     \  /     |
           |        \/        |        |      \/      |
           |        /\        |        |      /\      |
           |       /  \       |        |     /  \     |
           |      /    \      |        |    /    \    |
           |     |     |      |        |   |      |   |
          ----------   ----------    ---------   ---------
 with     |Switch1 |   |Switch2 |    |Switch3|   |Switch4|  withou
 DHCP     ----------   ----------    ---------   ---------  DHCP
 Snooping  |       \   /      |        |      \  /     |  Snooping
           |        \/        |        |       \/      |
           |        /\        |        |       /\      |
           |       /  \       |        |      /  \     |
          ----------   ----------    ----------  ----------
          |Server1 |   |Server2 |    |Server3 |  |Server4 |
          ----------   ----------    ----------  ----------
              |                                      |
             VM1                                   new VM1

               Figure 18: Heterogeneous functions on devices





Gu & Fan                Expires December 10, 2011              [Page 28]

Internet-Draft  policy and dynamic information migration       June 2011


5.4.  Resource Capability

   Even if destination devices can support specific function that is
   required by dynamic information migration, there might be not enough
   resources to implement migrated polices.  For example, there are 5
   connection state items related to VM1 on source LB.  However, the
   destination LB has only 4 table items available.  That means the
   destination LB doesn't have enough resource to support this VM
   migration, and policies migration on network devices may fail.

5.5.  Migration Feedback

   Sometimes, VM manager has ensure, by some way, that proper
   functionality and plenty of resources are available on destionation
   devices, by which we mean all the devices that need to handle VM's
   packets, but dynamic information migration still fails.  In this
   case, VM manager or Hypervisor needs to know the results of policy
   migration.  The feedback from network can help VM Manager to decide
   whether to rollback the migration or continue migration with risk.


6.  Security Considerations

   The policies and dynamic information described above are all about
   security.  Besides, we need to be careful to avoid poisoned polices
   from untrusted source.  That means no mather how the polices are
   migrated, be it distributed or centralized way, authentication and
   verification are required.

   A reliable notifation from server side to network side is also
   necessary, so that the destination and original devices can be sure
   that a real VM migration happens.


7.  Acknowledgments

   I would like to thank the following people for contributing to this
   draft: Ning Zong, David harrington, Linda dunbar, Susan Hares, Serge
   manning, Barry Leiba, Jiang xingfeng, Song Wei, Robert Sultan, and
   many others.


8.  References

8.1.  Normative Reference

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.



Gu & Fan                Expires December 10, 2011              [Page 29]

Internet-Draft  policy and dynamic information migration       June 2011


   [RFC3303]  , P., "Middlebox communication architecture and
              framework", August 2002.

8.2.  Informative Reference

   [Data_Center_Fundamentals]
              , Cisco Press., "Data Center Fundamentals", 2003.


Authors' Addresses

   Gu Yingjie
   Huawei
   No. 101 Software Avenue
   Nanjing, Jiangsu Province  210001
   P.R.China

   Phone: +86-25-56624760
   Fax:   +86-25-56624702
   Email: guyingjie@huawei.com


   Fan Yongbing
   China Telecom
   No. 109 Zhongshan Road West
   Guangzhou, Guangdong Province
   P.R.China

   Phone: 86-20-38639121
   Fax:   86-20-38639487
   Email: fanyb@gsta.com




















Gu & Fan                Expires December 10, 2011              [Page 30]


--Boundary_(ID_syjEGnl9pB2WJrEh/zMbQg)--

From salvatore.loreto@ericsson.com  Mon Jun 13 08:51:42 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE76011E811F for ; Mon, 13 Jun 2011 08:51:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.598
X-Spam-Level: 
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKisFr5z2OYw for ; Mon, 13 Jun 2011 08:51:41 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4832911E810B for ; Mon, 13 Jun 2011 08:51:41 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-d0-4df6320c8714
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 53.69.20773.C0236FD4; Mon, 13 Jun 2011 17:51:40 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 13 Jun 2011 17:51:39 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 1E223244F	for ; Mon, 13 Jun 2011 18:51:39 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D964150ABC	for ; Mon, 13 Jun 2011 18:51:38 +0300 (EEST)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 85B2B50A19	for ; Mon, 13 Jun 2011 18:51:38 +0300 (EEST)
Message-ID: <4DF6320A.3000701@ericsson.com>
Date: Mon, 13 Jun 2011 18:51:38 +0300
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: dispatch@ietf.org
References: <4DDA0388.60702@ericsson.com>
In-Reply-To: <4DDA0388.60702@ericsson.com>
Content-Type: multipart/alternative; boundary="------------090408080205090204020902"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [dispatch] charter proposal: SIP end-to-end Session Identifier
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Jun 2011 15:51:42 -0000

--------------090408080205090204020902
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi there,


the charter proposal [1] has got a slot for the Quebec City meeting and
on the list there seems to be a good support to initiating work on this 
item

comments on the charter proposal [1] and on the requirement draft for
an End-to-End Session identification [2] and the use cases described there
are very welcome



[1] http://www.ietf.org/mail-archive/web/dispatch/current/msg03647.html
[2] http://www.ietf.org/id/draft-jones-ipmc-session-id-reqts-00.txt



/Sal

-- 
Salvatore Loreto
www.sloreto.com



On 5/23/11 9:49 AM, Salvatore Loreto wrote:
>
> Hi there,
>
> below a charter proposal for a new wg working on End-to-end Session 
> Identifier in SIP.
>
>
> In an effort to make progress and to facilitate the discussion
> we have also created an Internet Draft that captures, at a high level,
> the requirements and use cases.
> (It was submitted by Paul E. Jones last Friday; here the link:
> http://www.ietf.org/id/draft-jones-ipmc-session-id-reqts-00.txt )
>
>
> cheers
> /Sal
>
> End-to-end Session Identifier in SIP (charter proposal )
> ----------------------------------------------
>
>
> The end-to-end Session Identifier in an SIP-based multimedia 
> communication refers to the ability
> for endpoints, intermediate devices, and management and monitoring 
> system to identify
> and correlate SIP messages and dialogs of the same higher-level 
> end-to-end "communication
> session" across multiple SIP devices and hops.
>
> Unfortunately, there are a number of factors that contribute to the 
> fact that the current
> dialog identifiers as defined in SIP is not suitable for end-to-end 
> session identification.
> Perhaps the most important factor worth describing is that in real-world
> deployments devices like Session Border Controllers (SBC) often change 
> the current call
> identifiers (e.g., the From-tag and To-tag that are used in 
> conjunction with the Call-ID header
> to make the dialog-id) as the session signaling passes through.
>
>
>
> An end-to-end Session Identifier should allow the possibility to 
> identify the communication session
> from the point of origin, passing through any number of 
> intermediaries, to the ultimate point
> of termination. It should have the same aim as the From-tag, To-tag 
> and Call-ID conjunction,
> but should not be mangled by intermediaries.
>
>
> A SIP end-to-end Session Identifier has been consideredas possible 
> solution of different use cases like
> troubleshooting, billing, session tracking, session recording, media 
> and signaling correlation, and so forth.
> Some of these requirements have also been identified and come directly 
> from other existing
> working group within the RAI area (e.g. SIPRec, Splices).
>
>
> Moreover, otherSDOs have identified the need for SIP and H.323 to 
> carry the same "session ID" value(s)
> so that it is possible identify a call end-to end even when performing 
> inter working between
> protocols.
>
>
> This group will first focus on adocument that will identify, collect 
> and discuss all the
> requirements and the use cases that have been identified.
> The document may identify the possibility to design a general 
> mechanism or the need
> to design multiple purpose built identifiers.
> Once the needs are clear and identified, the working group will 
> specify the mechanism(s).
>
>
> Specifically, the proposed working group will develop the following 
> deliverable:
>
>    1. A requirement and use case document with key consideration for
>       SIP Session
>       End-to-End identifier. The document will discuss the possibility
>       of designing
>       a general mechanism or the needs to design multiple purpose
>       build identifier.
>    2. Specification of new mechanism(s).
>
>
> Goal and Milestone:
>     October 2011 - Requirement and use case document sent to the IESG 
> (Information)
>


--------------090408080205090204020902
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit



  
    
    
  
  
    Hi there,

    

    

    the charter proposal [1] has got a slot for the Quebec City meeting
    and

    on the list there seems to be a good support to initiating work on
    this item 

    

    comments on the charter proposal [1] and on the requirement draft
    for

    an End-to-End Session identification [2] and the use cases described
    there

    are very welcome

    

    

    

    [1]
    http://www.ietf.org/mail-archive/web/dispatch/current/msg03647.html

    [2] http://www.ietf.org/id/draft-jones-ipmc-session-id-reqts-00.txt

    

    

    

    /Sal

    

    
-- 
Salvatore Loreto
www.sloreto.com

    

    

    On 5/23/11 9:49 AM, Salvatore Loreto wrote:
    

      
      
Hi there,

        

      
below a charter proposal for a
          new wg working on End-to-end Session Identifier in SIP.

        

      

      In an effort to make progress and to facilitate the discussion

      we have also created an Internet Draft that captures, at a high
      level, 

      the requirements and use cases.

      (It was submitted by Paul E. Jones last Friday; here the link: 

        http://www.ietf.org/id/draft-jones-ipmc-session-id-reqts-00.txt
        )

      
      


          cheers

          /Sal

        

      

      
End-to-end Session Identifier
          in SIP (charter proposal )

          ----------------------------------------------

        

      


          The end-to-end Session Identifier in an SIP-based multimedia
          communication refers to the ability

          for endpoints, intermediate devices, and management and
          monitoring system to identify

          and correlate SIP messages and dialogs of the same
          higher-level end-to-end "communication 

          session" across multiple SIP devices and hops. 

          

          Unfortunately, there are a number of factors that contribute
          to the fact that the current

          dialog identifiers as defined in SIP is not suitable for
          end-to-end session identification.

          Perhaps the most important factor worth describing is that in
          real-world 

          deployments devices like Session Border Controllers (SBC)
          often change the current call 

          identifiers (e.g., the From-tag and To-tag that are used in
          conjunction with the Call-ID header

          to make the dialog-id) as the session signaling passes
          through.

      


          

          An end-to-end Session Identifier should allow the possibility
          to identify the communication session

          from the point of origin, passing through any number of
          intermediaries, to the ultimate point

          of termination. It should have the same aim as the From-tag,
          To-tag and Call-ID conjunction,

          but should not be mangled by intermediaries. 

      


        A SIP end-to-end Session Identifier has been considered as possible solution
        of different use cases like 

        troubleshooting, billing, session tracking, session recording,
        media and signaling correlation, and so forth.

        Some of these requirements have also been identified and come
        directly from other existing 

        working group within the RAI area (e.g. SIPRec, Splices).

      


        Moreover, other SDOs

        have identified the need for SIP and H.323 to carry the same
        "session ID" value(s)

        so that it is possible identify a call end-to end even when
        performing inter working between

        protocols.

        

        

        This group will first focus on a document that will identify, collect and
        discuss all the 

        requirements and the use cases that have been identified.

        The document may identify the possibility to design a general
        mechanism or the need

        to design multiple purpose built identifiers. 

        Once the needs are clear and identified, the working group will
        specify the mechanism(s).

        

        

        Specifically, the proposed working group will develop the
        following deliverable:

      
    
        
  1. A requirement and
            use case document with key consideration for SIP Session
    
            End-to-End identifier. The document will discuss the
            possibility of designing
    
            a general mechanism or the needs to design multiple purpose
            build identifier.
    2. 
        
  2. Specification of
            new mechanism(s).
    3. 
      

      


        Goal and Milestone:

            October 2011 - Requirement and use case document sent to the
        IESG (Information)

      
 

    

    

  


--------------090408080205090204020902--

From bruno.chatras@orange-ftgroup.com  Tue Jun 14 02:13:18 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523CF9E800C for ; Tue, 14 Jun 2011 02:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.041
X-Spam-Level: 
X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[AWL=0.208,  BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1M1Q2Qu5W9t for ; Tue, 14 Jun 2011 02:13:17 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id AC3529E8017 for ; Tue, 14 Jun 2011 02:13:16 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7B36B738006; Tue, 14 Jun 2011 11:14:32 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 6C2B76D8003; Tue, 14 Jun 2011 11:14:32 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 14 Jun 2011 11:13:15 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 14 Jun 2011 11:13:13 +0200
Message-ID: <9ECCF01B52E7AB408A7EB8535264214102F5E3CE@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA0A4A2FF0@gaalpa1msgusr7e.ugd.att.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] SIP Load balancing (SIPLB) Charter proposal
Thread-Index: AcwlI7mmed+XiSHkQYGxFFc59kn/+QABrDoAADxf01AAIw4MoAADqpCwAAUcWcAAG/XmIAAJujqQAMLBBiA=
References: 	<9ECCF01B52E7AB408A7EB8535264214102E4435E@ftrdmel0.rd.francetelecom.fr>	<9ECCF01B52E7AB408A7EB8535264214102EE636C@ftrdmel0.rd.francetelecom.fr><4DEE3D38.3080106@bell-labs.com>	<9ECCF01B52E7AB408A7EB8535264214102F28BC2@ftrdmel0.rd.francetelecom.fr>	<14C85D6CCBE92743AF33663BF5D24EBA0A43F39F@gaalpa1msgusr7e.ugd.att.com><9ECCF01B52E7AB408A7EB8535264214102F297ED@ftrdmel0.rd.francetelecom.fr> <006d01cc26b7$1140ecc0$33c2c640$@us>  <9ECCF01B52E7AB408A7EB8535264214102F29ABE@ftrdmel0.rd.francetelecom.fr> <14C85D6CCBE92743AF33663BF5D24EBA0A4A2FF0@gaalpa1msgusr7e.ugd.att.com>
From: 
To: , , , 
X-OriginalArrivalTime: 14 Jun 2011 09:13:15.0230 (UTC) FILETIME=[4AD9DFE0:01CC2A73]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Jun 2011 09:13:18 -0000

I agree it should be an option not THE only solution. I just want to =
make sure that this option is not ruled out of the scope of the WG.

Actually the "DNS approach" does not over complicate the DNS. It just =
makes use of DNS UPDATE (RFC2136). The "complexity", if any, is not on =
the DNS itself but rather on=20

i) The logical entity that collects load information from the servers =
and updates the DNS using RFC2136. This logical entity can be co-located =
with the servers or implemented as a standalone off path node that uses =
e.g. SNMP to collect (or be notified of) load information

ii) The clients that make load balancing decisions based on priority and =
weight fields found in DNS records

Bruno

> -----Message d'origine-----
> De=A0: DOLLY, MARTIN C (ATTSI) [mailto:md3135@att.com]
> Envoy=E9=A0: vendredi 10 juin 2011 13:35
> =C0=A0: CHATRAS Bruno RD-CORE-ISS; partr@cisco.com; =
richard@shockey.us;
> vkg@bell-labs.com
> Cc=A0: dispatch@ietf.org
> Objet=A0: RE: [dispatch] SIP Load balancing (SIPLB) Charter proposal
>=20
> AT&T supports the approach in the current draft, and would view the
> "DNS approach" as an option.
> Let DNS do what it does well, and donot over complicate it.
>=20
> -----Original Message-----
> From: bruno.chatras@orange-ftgroup.com [mailto:bruno.chatras@orange-
> ftgroup.com]
> Sent: Friday, June 10, 2011 3:03 AM
> To: partr@cisco.com; richard@shockey.us; DOLLY, MARTIN C (ATTSI);
> vkg@bell-labs.com
> Cc: dispatch@ietf.org
> Subject: RE: [dispatch] SIP Load balancing (SIPLB) Charter proposal
>=20
> I think it's more than just a protocol issue. There are architectural
> aspects here as well (in-path vs. out-path load balancer). I think =
both
> approaches should be covered.
>=20
> In-path: All SIP traffic goes through the load balancer, which is
> itself a SIP entity
>=20
> Out-Path: SIP entities balance the load themselves, based on
> information received from a load balancer (DNS, 3GPP LDF or something
> else)
>=20
> Bruno
>=20
> > -----Message d'origine-----
> > De=A0: Parthasarathi R (partr) [mailto:partr@cisco.com]
> > Envoy=E9=A0: jeudi 9 juin 2011 19:45
> > =C0=A0: Richard Shockey; CHATRAS Bruno RD-CORE-ISS; md3135@att.com;
> > vkg@bell-labs.com
> > Cc=A0: dispatch@ietf.org
> > Objet=A0: RE: [dispatch] SIP Load balancing (SIPLB) Charter proposal
> >
> > Bruno,
> >
> > Thanks for your information about DNS based SIP load balancing in
> 3GPP
> > spec (in different mail thread).
> >
> > IMO, There are two parts in feedback based SIP load balancing
> >
> > 1) Feedback value
> > 2) Feedback protocol choice (SIP, DNS, SNMP)
> >
> > The current mail thread is about feedback protocol which has to be
> used.
> > I agree with you that it is possible for other protocols for SIP =
load
> > balancing. We will add the consideration and discuss in detail about
> > protocol choice to sort out the discussion.
> >
> >
> > I really didn't see the usage of DNS based load balancing mechanism
> in
> > Enterprise deployment. But initially, I have explored to use SNMP to
> > pass feedback value as a trap and I got the comments that SIP based
> > feedback mechanism will reduce the dependency on another protocol
> stack
> > in the system. I guess that the comment will apply for DNS as well
> and
> > also FQDN in SIP URI is not mandatory in SIP.
> >
> > Thanks
> > Partha
> >
> > -----Original Message-----
> > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] =
On
> > Behalf Of Richard Shockey
> > Sent: Thursday, June 09, 2011 8:38 PM
> > To: bruno.chatras@orange-ftgroup.com; md3135@att.com; vkg@bell-
> labs.com
> > Cc: dispatch@ietf.org
> > Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
> >
> >
> > Humm .. an application specific use of DNS technology in a closed
> > controlled environment.  I heard of these kind of things before.
> > Sounds like a interesting idea. :-)
> >
> > -----Original Message-----
> > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] =
On
> > Behalf Of bruno.chatras@orange-ftgroup.com
> > Sent: Thursday, June 09, 2011 9:28 AM
> > To: md3135@att.com; vkg@bell-labs.com
> > Cc: dispatch@ietf.org
> > Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
> >
> > Hi Martin,
> > The load balancing capability can be implemented on dedicated DNS
> > servers only. This does not put the service provider's DNS
> > infrastructure at risk.
> > Bruno
> >
> >
> > > -----Message d'origine-----
> > > De=A0: DOLLY, MARTIN C (ATTSI) [mailto:md3135@att.com] =
Envoy=E9=A0:
> > mercredi
> > > 8 juin 2011 22:39 =C0=A0: CHATRAS Bruno RD-CORE-ISS; =
vkg@bell-labs.com
> > Cc
> > > : dispatch@ietf.org Objet=A0: RE: [dispatch] SIP Load balancing
> (SIPLB)
> > > Charter proposal
> > >
> > > Bruno,
> > >
> > > Do we really want to impact the DNS with a load balancing
> capability
> > > linked to overload control?
> > >
> > > Martin
> > >
> > > -----Original Message-----
> > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org]
> On
> > > Behalf Of bruno.chatras@orange-ftgroup.com
> > > Sent: Tuesday, June 07, 2011 11:54 AM
> > > To: vkg@bell-labs.com
> > > Cc: dispatch@ietf.org
> > > Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter =
proposal
> > >
> > > Vijay,
> > >
> > > Speaking as a representative of a Service Provider, I can tell you
> > > that we are interested in DNS-based solutions. I believe that the
> WG
> > > should address both types of solutions.
> > >
> > > Bruno
> > >
> > > > -----Message d'origine-----
> > > > De=A0: Vijay K. Gurbani [mailto:vkg@bell-labs.com] Envoy=E9=A0: =
mardi 7
> > > > juin 2011 17:01 =C0=A0: CHATRAS Bruno RD-CORE-ISS Cc=A0:
> partr@cisco.com;
> > > > dispatch@ietf.org Objet=A0: Re: [dispatch] SIP Load balancing
> (SIPLB)
> > > > Charter proposal
> > > >
> > > > On 06/07/2011 04:13 AM, bruno.chatras@orange-ftgroup.com wrote:
> > > > bruno> Comment: In the list of considerations that must be taken
> > > > bruno> into
> > > > account I
> > > > bruno> would add =AB Whether the load balancer is SIP-aware or =
not.
> > > > bruno>
> > > > partha> Till now, we are discussing about SIP-aware load =
balancer
> > > only.
> > > > partha> In case the load balancer is SIP-unaware, is it =
something
> > > like
> > > > partha> load-balance by open-loop model wherein there is no
> > feedback
> > > > required
> > > > partha> from downstream servers or load balance in the transport
> > > layer
> > > > instead
> > > > partha> of SIP layer ?. Could you please explain your
> consideration
> > > in
> > > > detail.
> > > > partha>
> > > > bruno> I was referring to a load balancer at the transport layer
> > > > bruno> with feedback from downstream servers./*
> > > >
> > > > Dear Bruno: I envision a SIP-aware load balancer with feedback
> > > > mechanism, where the feedback is carried in SIP signaling.
> > > >
> > > > More inline.
> > > >
> > > > bruno> Question: Is the Charter intended to cover architectures
> > with
> > > an
> > > > in-path
> > > > bruno> load balancer in front of a farm of SIP servers only or =
is
> > it
> > > > expected
> > > > bruno> to cover as well other architectures where the load
> balancer
> > > is
> > > > off-path
> > > > bruno> or even architectures where load balancing just relies on
> > > > frequent
> > > > bruno> updates of the DNS?
> > > >
> > > > My understanding is that service providers are loath to update
> DNS.
> > > > As such, a solution that does not depend on DNS is preferable.
> > > > This, then, means that an in-path solution that does not require
> > DNS
> > > > would be the most preferred.
> > > >
> > > > I note that the LDF function you mention from [1] is a backward
> > > > feedback solution with the LDF updating the DNS periodically.
> > > >
> > > > I think that it would be good to have substantive input from the
> > > > service provider community as well as the working group to
> > determine
> > > > whether a solution that does not depend on DNS being updated is
> > > > preferred or not.
> > > >
> > > > Thoughts?
> > > >
> > > > [1] =
http://www.3gpp.org/ftp/Specs/archive/23_series/23.812/23812-
> > > > 115.zip
> > > >
> > > > Thanks,
> > > >
> > > > - vijay
> > > > --
> > > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent
> > > > Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> > > > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-
> > lucent.com
> > > > Web:   http://ect.bell-labs.com/who/vkg/
> > > _______________________________________________
> > > dispatch mailing list
> > > dispatch@ietf.org
> > > https://www.ietf.org/mailman/listinfo/dispatch
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> >
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch

From arnoud.vanwijk@realtimetext.org  Tue Jun 21 02:32:35 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79ADF21F858D for ; Tue, 21 Jun 2011 02:32:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.165
X-Spam-Level: 
X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjfwDpk5uWvD for ; Tue, 21 Jun 2011 02:32:34 -0700 (PDT)
Received: from mx-in01.nouzelle.com (mx-in01.nouzelle.com [87.119.194.132]) by ietfa.amsl.com (Postfix) with ESMTP id 3779A21F858B for ; Tue, 21 Jun 2011 02:32:33 -0700 (PDT)
Received: from internal02.nouzelle.com (internal02.nouzelle.local [172.29.32.13]) by mx-in01.nouzelle.com (Postfix) with ESMTP id E8415125BDB for ; Tue, 21 Jun 2011 11:30:57 +0200 (CEST)
Received: from mailscan.nouzelle.com (unknown [172.29.32.10]) by internal02.nouzelle.com (Postfix) with ESMTP id D662A10219AD0 for ; Tue, 21 Jun 2011 11:32:31 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at nouzelle.com
Received: from internal02.nouzelle.com ([172.29.32.13]) by mailscan.nouzelle.com (mailscan.nouzelle.com [172.29.32.10]) (amavisd-new, port 10026) with ESMTP id Eh9sL+bOR97G for ; Tue, 21 Jun 2011 11:32:30 +0200 (CEST)
Received: from arnoud-van-wijks-macbook-pro.local (541BD3CF.cm-5-4d.dynamic.ziggo.nl [84.27.211.207]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by internal02.nouzelle.com (Postfix) with ESMTPSA id D196B10219ACE for ; Tue, 21 Jun 2011 11:32:30 +0200 (CEST)
Message-ID: <4E00652E.8000804@realtimetext.org>
Date: Tue, 21 Jun 2011 11:32:30 +0200
From: Arnoud van Wijk 
Organization: R3TF
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: dispatch@ietf.org
References: <4DDE3268.2030307@realtimetext.org> <4DEF2BE7.9090306@realtimetext.org>
In-Reply-To: <4DEF2BE7.9090306@realtimetext.org>
Content-Type: multipart/alternative; boundary="------------060100080307050305020400"
Subject: Re: [dispatch] Text media handling in RTP based real-time conferences
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: arnoud.vanwijk@realtimetext.org
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jun 2011 09:32:35 -0000

This is a multi-part message in MIME format.
--------------060100080307050305020400
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I want to add an additional comment why this draft is important and why 
we need this work as a separate draft despite that media handling in RTP 
conferences should not matter using text, video or audio.

This draft is actually a BCP. It specifies the recommended procedures to 
follow in implementations among the enormous amount of available 
options. We have encountered the confusion many times where implementers 
are scratching behind their ears and ask what is the best way?
By publishing this BCP we increase the likelihood of interoperability of 
different solutions in a significant way, and that is an enormously 
important task for us as IETF.

Sincerely,

Arnoud van Wijk



On 08-06-11 09:59, Arnoud van Wijk wrote:
> Hi everybody,
>
> Since this draft was submitted in March ago, I like to ask DISPATCH if 
> the AVTCORE WG is the best WG for it.
> I think so, since this does handle media handling in conferences.
> We have edited this draft based on the discussions in AVT core in 
> march about SSRC multiplexing.
>
> It is very important that when using RTT streams in a multiparty call 
> that it will work with all SIP based call control environments.
> I feel that we need together with AVT to work out the details to 
> ensure that this remains possible.
>
> Several solutions are currently being implemented in RTT systems by 
> several companies and the longer we wait..the harder it gets to ensure 
> the best implementation to be used.
>
> So, this is quite important for real-world cases.
>
> I am looking forward to your feedback as always.
>
> sincerely
>
> Arnoud van Wijk
>
>
>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>> 	Title           : Text media handling in RTP based real-time conferences
>> 	Author(s)       : G. Hellstrom, A. Wijk
>> 	Filename        : draft-hellstrom-text-conference-04.txt
>> 	Pages           : 9
>> 	Date            : 2011-03-14
>>
>> This memo specifies methods for text media handling in multi-party
>> calls, where the text is carried by the RTP protocol.  Real-time text
>> is carried in a time-sampled mode according to RFC 4103.  Centralized
>> multi-party handling of real-time text is achieved through a media
>> control unit coordinating multiple RTP text streams into one single
>> stream RTP session, identifying each stream with its own CSRC.
>> Identification for the streams are provided through the RTCP
>> messages.  This mechanism enables the receiving application to
>> present the received real-time text medium in different ways
>> according to user preferences.  Some presentation related features
>> are also described explaining suitable variations of transmission and
>> presentation of text.  Call control features are described for the
>> SIP environment, while the transport mechanisms should be suitable
>> for any IP based call control environment using RTP transport.  Two
>> alternative methods using a single RTP stream and source
>> identification inline in the text stream are also described.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-hellstrom-text-conference-04.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>> 
>>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

--------------060100080307050305020400
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
    
  
  
    I want to add an additional comment why this draft is important and
    why we need this work as a separate draft despite that media
    handling in RTP conferences should not matter using text, video or
    audio.

    

    This draft is actually a BCP. It specifies the recommended
    procedures to follow in implementations among the enormous amount of
    available options. We have encountered the confusion many times
    where implementers are scratching behind their ears and ask what is
    the best way?

    By publishing this BCP we increase the likelihood of
    interoperability of different solutions in a significant way, and
    that is an enormously important task for us as IETF.

    

    Sincerely,

    

    Arnoud van Wijk

    

    

    

    On 08-06-11 09:59, Arnoud van Wijk wrote:
    

      
      
      Hi everybody,

      

      Since this draft was submitted in March ago, I like to ask
      DISPATCH if the AVTCORE WG is the best WG for it.

      I think so, since this does handle media handling in conferences.

      We have edited this draft based on the discussions in AVT core in
      march about SSRC multiplexing.

      

      It is very important that when using RTT streams in a multiparty
      call that it will work with all SIP based call control
      environments.

      I feel that we need together with AVT to work out the details to
      ensure that this remains possible.

      

      Several solutions are currently being implemented in RTT systems
      by several companies and the longer we wait..the harder it gets to
      ensure the best implementation to be used.

      

      So, this is quite important for real-world cases.

      

      I am looking forward to your feedback as always.

      

      sincerely

      

      Arnoud van Wijk

      

      

      

      

        
A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Text media handling in RTP based real-time conferences
	Author(s)       : G. Hellstrom, A. Wijk
	Filename        : draft-hellstrom-text-conference-04.txt
	Pages           : 9
	Date            : 2011-03-14

This memo specifies methods for text media handling in multi-party
calls, where the text is carried by the RTP protocol.  Real-time text
is carried in a time-sampled mode according to RFC 4103.  Centralized
multi-party handling of real-time text is achieved through a media
control unit coordinating multiple RTP text streams into one single
stream RTP session, identifying each stream with its own CSRC.
Identification for the streams are provided through the RTCP
messages.  This mechanism enables the receiving application to
present the received real-time text medium in different ways
according to user preferences.  Some presentation related features
are also described explaining suitable variations of transmission and
presentation of text.  Call control features are described for the
SIP environment, while the transport mechanisms should be suitable
for any IP based call control environment using RTP transport.  Two
alternative methods using a single RTP stream and source
identification inline in the text stream are also described.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hellstrom-text-conference-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


        

          
<ftp://ftp.ietf.org/internet-drafts/draft-hellstrom-text-conference-04.txt>

        

      

      

      

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


    

  


--------------060100080307050305020400--

From arnoud.vanwijk@realtimetext.org  Tue Jun 21 02:43:50 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0141F9E8046 for ; Tue, 21 Jun 2011 02:43:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.274
X-Spam-Level: 
X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgqTPL2qKYY9 for ; Tue, 21 Jun 2011 02:43:49 -0700 (PDT)
Received: from mx-in02.nouzelle.com (mx-in02.nouzelle.com [87.119.194.141]) by ietfa.amsl.com (Postfix) with ESMTP id D8EEA9E802B for ; Tue, 21 Jun 2011 02:43:48 -0700 (PDT)
Received: from internal02.nouzelle.com (mail.local [172.29.32.13]) by mx-in02.nouzelle.com (Postfix) with ESMTP id A2CE210214208 for ; Tue, 21 Jun 2011 11:43:46 +0200 (CEST)
Received: from mailscan.nouzelle.com (unknown [172.29.32.10]) by internal02.nouzelle.com (Postfix) with ESMTP id 8387D10219AD0 for ; Tue, 21 Jun 2011 11:43:46 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at nouzelle.com
Received: from internal02.nouzelle.com ([172.29.32.13]) by mailscan.nouzelle.com (mailscan.nouzelle.com [172.29.32.10]) (amavisd-new, port 10026) with ESMTP id REWHNVlZlOzN for ; Tue, 21 Jun 2011 11:43:36 +0200 (CEST)
Received: from arnoud-van-wijks-macbook-pro.local (541BD3CF.cm-5-4d.dynamic.ziggo.nl [84.27.211.207]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by internal02.nouzelle.com (Postfix) with ESMTPSA id 0971C10219AC3 for ; Tue, 21 Jun 2011 11:43:35 +0200 (CEST)
Message-ID: <4E0067C7.1070705@realtimetext.org>
Date: Tue, 21 Jun 2011 11:43:35 +0200
From: Arnoud van Wijk 
Organization: R3TF
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: dispatch@ietf.org
References: <4DDE3268.2030307@realtimetext.org>
In-Reply-To: <4DDE3268.2030307@realtimetext.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dispatch] Presentation of Text Conversation in real-time and en-bloc form
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: arnoud.vanwijk@realtimetext.org
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jun 2011 09:43:50 -0000

Some more explanation why this draft is valuable:
The use of RTT in combination with en-bloc systems (Instant Messaging) 
and multiple RTT users is a new territory for most of us at the IETF.
This draft is a actually a BCP specifying the recommended procedures to 
follow in implementations among the enormous amount of available 
options. In this way we want to prevent that many implementers are 
unsure or getting confused on *what is the best way* to add RTT to the 
clients/system interfaces and how to present it to the user.

That is why this draft contains new material on the presentation level. 
In most IETF publications the presentation level is seldom described, 
but in this case very positive comments have been made about that this 
draft deals with that important level.  It is also important for the end 
- to - end interoperability to describe the possible presentations.

I hope that this does clarify why we have this draft so that we can 
ensure good working interoperable systems with RTT included.

Sincerely

Arnoud van Wijk

On 26-05-11 12:58, Arnoud van Wijk wrote:
> Hi all,
> This draft is about Real-Time Text (RTT) presented in real-time and as 
> well in en-bloc mode.
> This is an ideal combination of both methods.
> You will see the text as it is being typed on a character by character 
> mode, but after hitting send or enter, the text will then appear 
> en-bloc. So the users can immediately follow the RTT part while the 
> sender is typing it or wait till it is show as en-bloc or use as a 
> combination depending on the intensity of the conversation.
> We are also describing how multiple users simultaneously talking via 
> RTT can be presented to the users.
> That part is relevant for the draft 
> http://www.ietf.org/id/draft-hellstrom-text-conference-04.txt
>
> We feel that this document is quite valuable, since we are getting a 
> lot of questions by people on this area.
> We would like to work with DISPATCH on how to proceed with this draft 
> and the text-conference draft.
>
> I am looking forward to your advice and comments. And also which 
> working group is the best "home" for both drafts.
>
> Sincerely
>
> Arnoud
>
>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>>
>>     Title           : Presentation of Text Conversation in real-time 
>> and en-bloc form
>>     Author(s)       : Gunnar Hellstrom
>>                            Arnoud van Wijk
>>                            Gregg C. Vanderheiden
>>                            Norman Williams
>>     Filename        : draft-hellstrom-textpreview-08.txt
>>     Pages           : 18
>>     Date            : 2011-05-25
>>
>>     This specification defines methods for presentation of a text
>>     conversation with focus on the real-time features.  The aim is to
>>     give the participants in a conversation a good opportunity to
>>     perceive the real-time flow of the conversation and also provide a
>>     display of the history of the conversation that makes it easy to
>>     read.  Both two-party and multi-party situations are defined.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-08.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-hellstrom-textpreview-08.txt
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

From fluffy@cisco.com  Fri Jun 24 07:27:12 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC8711E80A1 for ; Fri, 24 Jun 2011 07:27:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.059
X-Spam-Level: 
X-Spam-Status: No, score=-110.059 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSfWk4hc5jco for ; Fri, 24 Jun 2011 07:27:11 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id C610111E8076 for ; Fri, 24 Jun 2011 07:27:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=221; q=dns/txt; s=iport; t=1308925631; x=1310135231; h=from:content-transfer-encoding:subject:date:references: to:message-id:mime-version; bh=2nrmkGJGxMq9HubuKWPvbkJz1YNVs1lJT8/ngHoYg5g=; b=F2IjM/RN+e2X0sdVJFZE9DMYaBoIGFHjVl+WKFBmYuPQD+/59xU6urqG hRERnLxxB4liGexoqoadub2IQJVgMjtl7J6qzhha1eV9ekmkw2im/f38p EocHEwU3CWAUW76VC3y+ECM5xwcPzLc3Xp/Isj46KtsMbjIPSfFILf0Nd A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Am8IAFeeBE6rRDoJ/2dsb2JhbABSLacJd4hzo2SeEYYtBIcpilKEaItK
X-IronPort-AV: E=Sophos;i="4.65,419,1304294400"; d="scan'208";a="385559598"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 24 Jun 2011 14:27:05 +0000
Received: from [192.168.4.101] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5OER0KD011402 for ; Fri, 24 Jun 2011 14:27:01 GMT
From: Cullen Jennings 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Thu, 23 Jun 2011 21:19:04 -0700
References: <20110623225728.18AAF11E8081@ietfa.amsl.com>
To: DISPATCH list 
Message-Id: <0ABE401B-DBF4-4170-99EB-946F55AC0F9C@cisco.com>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [dispatch] DISPATCH - Requested session has been scheduled for IETF 81
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 14:27:12 -0000

Tentative time for dispatch meeting 

Begin forwarded message:

> 
> DISPATCH Session 1 (2 hours)
> Monday, Morning Session I 0900-1130
> Room Name: 205 ABC
> ----------------------------------------------
> 


From Mary.Barnes@Polycom.com  Thu Jun 23 16:36:03 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6E911E81A0 for ; Thu, 23 Jun 2011 16:36:03 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ydrs6VP5FQD5 for ; Thu, 23 Jun 2011 16:36:03 -0700 (PDT)
Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 1587611E80D8 for ; Thu, 23 Jun 2011 16:36:01 -0700 (PDT)
Received: from CRPMBOXPRD02.polycom.com ([fe80::b94b:feef:580:da7f]) by crpehubprd02.polycom.com ([fe80::1c3e:2e7c:4b4f:14fd%10]) with mapi; Thu, 23 Jun 2011 16:36:00 -0700
From: "Barnes, Mary" 
To: "dispatch@ietf.org" 
Date: Thu, 23 Jun 2011 16:35:59 -0700
Thread-Topic: DISPATCH - Requested session has been scheduled for IETF 81 
Thread-Index: Acwx+O6887HE9xjoRaW7SmHyjIYA/wABUfAw
Message-ID: <4483E11778CA964F9644B68621E1CA464B1D2E27@CRPMBOXPRD02.polycom.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 24 Jun 2011 13:12:29 -0700
Subject: [dispatch] FW: DISPATCH - Requested session has been scheduled for IETF 81
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 20:11:41 -0000

RllJLi4ud2UgaGF2ZSB0aGUgZmlyc3QgbWVldGluZyBzbG90IG9uIE1vbmRheSBtb3JuaW5nIC0g
YXQgdGhpcyB0aW1lLiAgQXMgYWx3YXlzLCB0aGUgc2NoZWR1bGUgaXMgc3ViamVjdCB0byBjaGFu
Z2UuDQoNClJlZ2FyZHMsDQpNYXJ5Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv
bTogSUVURiBTZWNyZXRhcmlhdCBbbWFpbHRvOmFnZW5kYUBpZXRmLm9yZ10gDQpTZW50OiBUaHVy
c2RheSwgSnVuZSAyMywgMjAxMSA1OjU3IFBNDQpUbzogQmFybmVzLCBNYXJ5DQpDYzogZmx1ZmZ5
QGNpc2NvLmNvbTsgZ29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tOyByanNwYXJrc0Bub3N0
cnVtLmNvbTsgc2Vzc2lvbi1yZXF1ZXN0QGlldGYub3JnDQpTdWJqZWN0OiBESVNQQVRDSCAtIFJl
cXVlc3RlZCBzZXNzaW9uIGhhcyBiZWVuIHNjaGVkdWxlZCBmb3IgSUVURiA4MSANCg0KRGVhciBN
YXJ5IEJhcm5lcywNCg0KVGhlIHNlc3Npb25zIHRoYXQgeW91IGhhdmUgcmVxdWVzdGVkIGhhdmUg
YmVlbiBzY2hlZHVsZWQuDQpCZWxvdyBpcyB0aGUgc2NoZWR1bGVkIHNlc3Npb24gaW5mb3JtYXRp
b24gZm9sbG93ZWQgYnkgDQp0aGUgaW5mb3JtYXRpb24gb2Ygc2Vzc2lvbnMgdGhhdCB5b3UgaGF2
ZSByZXF1ZXN0ZWQuDQoNCkRJU1BBVENIIFNlc3Npb24gMSAoMiBob3VycykNCk1vbmRheSwgTW9y
bmluZyBTZXNzaW9uIEkgMDkwMC0xMTMwDQpSb29tIE5hbWU6IDIwNSBBQkMNCi0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNClJlcXVlc3RlZCBJbmZv
cm1hdGlvbjoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCldvcmtpbmcgR3JvdXAgTmFtZTogZGlzcGF0Y2gNCkFyZWEgTmFtZTog
UmVhbC10aW1lIEFwcGxpY2F0aW9ucyBhbmQgSW5mcmFzdHJ1Y3R1cmUgQXJlYQ0KU2Vzc2lvbiBS
ZXF1ZXN0ZXI6IE1hcnkgQmFybmVzDQoNCk51bWJlciBvZiBTZXNzaW9uczogMQ0KTGVuZ3RoIG9m
IFNlc3Npb24ocyk6ICAyIGhvdXJzDQogICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAg
ICAgICAgICAgICAgICANCk51bWJlciBvZiBBdHRlbmRlZXM6IDIwMA0KQ29uZmxpY3RzIHRvIEF2
b2lkOg0KICBGaXJzdCBQcmlvcml0eTogYXRvY2EgYXZ0Y29yZSBhdnRleHQgYmxpc3MgY29kZWMg
Y2x1ZSBjdXNzIGRyaW5rcyBlY3JpdCAgZ2VvcHJpdiBtbXVzaWMgcGF5bG9hZCBwMnBzaXAgcnRj
d2ViIHNhbHVkIHNpbXBsZSBzaXBjbGYgc2lwY29yZSBzaXByZWMgc29jIHNwbGljZXMgc3BlZXJt
aW50IHZpcHIgeGNvbiB4bXBwIHhyYmxvY2sgDQogIFNlY29uZCBQcmlvcml0eTogIGhpcCBjb3Jl
IGFsdG8gb3BzYXJlYSB0c3Z3ZyB0c3ZhcmVhDQoNClNwZWNpYWwgUmVxdWVzdHM6DQogIA0KLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN
Cg0K

From mary.ietf.barnes@gmail.com  Fri Jun 24 13:54:57 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6228511E823F for ; Fri, 24 Jun 2011 13:54:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.765
X-Spam-Level: 
X-Spam-Status: No, score=-102.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScgxaBSnwpyp for ; Fri, 24 Jun 2011 13:54:56 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5787711E8242 for ; Fri, 24 Jun 2011 13:54:55 -0700 (PDT)
Received: by vxi40 with SMTP id 40so3225528vxi.31 for ; Fri, 24 Jun 2011 13:54:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=GHbG3rBIK2s2Xhd7mgICP5xyzz1MjigEYltdr/62KZc=; b=srlYfsVxkHQejcCjfGkVblIs5JpAImQffU+LGnoGBLXN62AJtND9FeeqZRC6qSxCoP Es/B8mZ1+1/9px7jqTfmNiZ7UukTqka0y8Xnsoy+WvTE5w6INyTd4e5Kv5SeEOZtB/1z Q94rbJiDx6sre3FJNMyMdqJHwerwr0yW+BKE8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=sh7eo4SAoviD09sB4eYS9pHH8zeof4QSta+HOFes3FtCVdIZEbPHkdzDlBcO9CCjd7 ccPQ8z4ZU8dkb2c7IbubZ+TnYEJlKJgm86EA3d9EZCfoikpjWz7Bm/qWs4iwPbXBDYC+ A3zJ6qQIsh5wzN2ukZ1w6D3gohKiCCkj3HYtc=
MIME-Version: 1.0
Received: by 10.52.89.4 with SMTP id bk4mr5301586vdb.143.1308948894549; Fri, 24 Jun 2011 13:54:54 -0700 (PDT)
Received: by 10.52.158.39 with HTTP; Fri, 24 Jun 2011 13:54:54 -0700 (PDT)
In-Reply-To: <4E04D399.1080400@ericsson.com>
References: <4E04D399.1080400@ericsson.com>
Date: Fri, 24 Jun 2011 15:54:54 -0500
Message-ID: 
From: Mary Barnes 
To: DISPATCH 
Content-Type: multipart/alternative; boundary=20cf307f336ce3850c04a67b6928
Subject: [dispatch] Fwd: Nomcom 2011-2012: Second Call for Volunteers
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 20:54:57 -0000

--20cf307f336ce3850c04a67b6928
Content-Type: text/plain; charset=ISO-8859-1

For folks that are not on the IETF discussion or announcement lists, please
read this email on the Call for volunteers for the 2011-2012 Nominations
committee.   This is one of the most important positions you can be
(randomly) selected for in terms of serving the community.

Regards,
Mary
DISPATCH WG co-chair
Past Nomcom Chair/Advisor

---------- Forwarded message ----------
From: Suresh Krishnan 
Date: Fri, Jun 24, 2011 at 1:12 PM
Subject: Nomcom 2011-2012: Second Call for Volunteers
To: IETF Discussion 


This is the Second call for Volunteers for the 2011-12 Nomcom.  We are
just about halfway through the volunteer period so if you are considering
volunteering, please do so very soon.

We have had a very good response to the initial call for volunteers and
I am pleased to report that we have 50 volunteers thus far whose
qualifications have been confirmed by the secretariat. I have notified
each of these volunteers by email.

However, we would like to have many more volunteers. The more volunteers,
the better chance we have of choosing a random yet representative cross
section of the IETF population. You have until 11:59 pm EDT July 10, 2011
to volunteer for Nomcom but it would be much better if you can volunteer
as early as possible.

If you volunteered before 21:00 EDT on June 21 to serve as a voting member
and have not received a confirmation email from me, please re-submit and
bring to my attention right away!

Details about the process for volunteering for the Nomcom and the list
of open positions for which the nominating committee is responsible are
summarized in the initial announcement:

https://datatracker.ietf.org/**ann/nomcom/2938/

The 50 volunteers who have thus far been qualified by the secretariat
are:

Alia Atlas , Juniper Networks
Lixia Zhang , UCLA
Wassim Haddad  , Ericsson
Glen Zorn , Network Zen
Richard Barnes , BBN Technologies
Stephen Kent , BBN Technologies
Scott Mansfield , Ericsson
Tina TSOU , FutureWei Technologies
Fernando Gont , UTN/FRH
Karen Seo , BBN Technologies
Jie Dong , Huawei Technologies
Mach Chen , Huawei Technologies Co.
Sheng Jiang , Huawei Technologies Co. Ltd.
Dimitri Papadimitriou , Alcatel-Lucent
Thomas D. Nadeau , CA Technologies
David Meyer , Cisco Systems/University of Oregon
Wesley George , Time Warner Cable
Cullen Jennings , Cisco
Stephen Hanna , Juniper Networks
Stephan Wenger , Bidyo
Keyur Patel , Cisco Systems
Michael Hamilton , BreakingPoint Systems
Behcet Sarikaya , Huawei USA
Mark Townsley , Cisco Systems
Fred Baker , Cisco Systems
Brian Trammell , ETH Zurich
Sam Hartman , Painless Security
Chris Griffiths , Comcast
George Michaelson , APNIC
Jiankang Yao , CNNIC
Sohel Khan , Comcast
Dacheng Zhang , Huawei
Lianshu Zheng , Huawei Technologies
Hui Deng , China Mobile
Gang Chen , China Mobile
Mirja Kuhlewind , University of Stuttgart
John E Drake , Juniper Networks
Matt Lepinski , BBN Technologies
Subir Das , Telcordia Technologies Inc
Yi Zhao , Huawei
John Scudder , Juniper Networks
Christer Holmberg , LM Ericsson
Teemu Savolainen , Nokia
Samita Chakrabarti , Ericsson
Jaap Akkerhuis , NLnet labs
Jason Weil , Time Warner Cable
Randy Bush , Internet Initiative Japan
Christian Schmidt , Nokia Siemens Networks
Sean Shen , CNNIC
Lou Berger , LabN Consulting

The primary activity for this nomcom will begin during IETF-81 in
Quebec City and should be completed by January 2012. The nomcom will
be collecting requirements from the community, as well as talking to
candidates and to community members about candidates. There will be
regularly scheduled conference calls to ensure progress. Thus, being a
nomcom member does require some time commitment.

Please volunteer by sending an email to me before
11:59 pm EDT July 10, 2011 as follows:

To: suresh.krishnan@ericsson.com
Subject: Nomcom 2011-12 Volunteer

Please include the following information in the body of the mail:

Full Name:  // As you enter in the IETF Registration Form,
           // First/Given name followed by Last/Family Name

Current Primary Affiliation: // typically what goes in the Company
                            // field in the IETF Registration Form

Email Address(es): // all email addresses used to Register for the
                  // past 5 IETF meetings
                  // Please designate a Preferred email address for
                  // contact if there is more than one email address

Telephone number:  // With country code (for confirmation if selected)

Please expect an email response from me within 3 business days stating
whether or not you are qualified.  If you do not receive a response in
this timeframe, please re-send your email with the tag "RESEND:" added
to the subject line.

If you are not yet sure you would like to volunteer, please consider
that Nomcom members play a very important role in shaping the
leadership of the IETF.  Ensuring the leadership of the IETF is fair
and balanced and comprised of those who can lead the IETF in the right
direction is an important responsibility that rests on the IETF
participants at large. Volunteering for the Nomcom is a good way of
contributing in that direction.

I will be publishing a more detailed target timetable, as well as
details of the randomness seeds to be used for the RFC 3797 selection
process within the next few days.

Thank you in advance for your participation.

Suresh Krishnan
Nomcom Chair 2011-2012
Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com

______________________________**_________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/**listinfo/ietf-announce
______________________________**_________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/**listinfo/ietf

--20cf307f336ce3850c04a67b6928
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

For folks that are not on the IETF discussion or announcement lists, please=
 read this email on the Call for volunteers for the 2011-2012 Nominations c=
ommittee. =A0 This is one of the most important positions you can be (rando=
mly) selected for in terms of serving the community.=A0


Regards,
Mary
DISPATCH WG co-chair
=

Past Nomcom Chair/Advisor

----------=
 Forwarded message ----------
From: Suresh=
 Krishnan <suresh.krishnan@ericsson.com>

Date: Fri, Jun 24, 2011 at 1:12 PM
Subject: Nomcom 2011-2012: Second Cal=
l for Volunteers
To: IETF Discussion <ietf@ietf.org>


This is the Second call for Volunteers f=
or the 2011-12 Nomcom. =A0We are


just about halfway through the volunteer period so if you are considering
volunteering, please do so very soon.



We have had a very good response to the initial call for volunteers and

I am pleased to report that we have 50 volunteers thus far whose

qualifications have been confirmed by the secretariat. I have notified

each of these volunteers by email.



However, we would like to have many more volunteers. The more volunteers,
the better chance we have of choosing a random yet representative cross

section of the IETF population. You have until 11:59 pm EDT July 10, 2011
to volunteer for Nomcom but it would be much better if you can volunteer
as early as possible.



If you volunteered before 21:00 EDT on June 21 to serve as a voting member<=
br>
and have not received a confirmation email from me, please re-submit and
bring to my attention right away!



Details about the process for volunteering for the Nomcom and the list

of open positions for which the nominating committee is responsible are

summarized in the initial announcement:



https://datatracker.ietf.org/ann/nomcom/2938/



The 50 volunteers who have thus far been qualified by the secretariat

are:



Alia Atlas , Juniper Networks

Lixia Zhang , UCLA

Wassim Haddad =A0, Ericsson

Glen Zorn , Network Zen

Richard Barnes , BBN Technologies

Stephen Kent , BBN Technologies

Scott Mansfield , Ericsson

Tina TSOU , FutureWei Technologies

Fernando Gont , UTN/FRH

Karen Seo , BBN Technologies

Jie Dong , Huawei Technologies

Mach Chen , Huawei Technologies Co.

Sheng Jiang , Huawei Technologies Co. Ltd.

Dimitri Papadimitriou , Alcatel-Lucent

Thomas D. Nadeau , CA Technologies

David Meyer , Cisco Systems/University of Oregon

Wesley George , Time Warner Cable

Cullen Jennings , Cisco

Stephen Hanna , Juniper Networks

Stephan Wenger , Bidyo

Keyur Patel , Cisco Systems

Michael Hamilton , BreakingPoint Systems

Behcet Sarikaya , Huawei USA

Mark Townsley , Cisco Systems

Fred Baker , Cisco Systems

Brian Trammell , ETH Zurich

Sam Hartman , Painless Security

Chris Griffiths , Comcast

George Michaelson , APNIC

Jiankang Yao , CNNIC

Sohel Khan , Comcast

Dacheng Zhang , Huawei

Lianshu Zheng , Huawei Technologies

Hui Deng , China Mobile

Gang Chen , China Mobile

Mirja Kuhlewind , University of Stuttgart

John E Drake , Juniper Networks

Matt Lepinski , BBN Technologies

Subir Das , Telcordia Technologies Inc

Yi Zhao , Huawei

John Scudder , Juniper Networks

Christer Holmberg , LM Ericsson

Teemu Savolainen , Nokia

Samita Chakrabarti , Ericsson

Jaap Akkerhuis , NLnet labs

Jason Weil , Time Warner Cable

Randy Bush , Internet Initiative Japan

Christian Schmidt , Nokia Siemens Networks

Sean Shen , CNNIC

Lou Berger , LabN Consulting



The primary activity for this nomcom will begin during IETF-81 in

Quebec City and should be completed by January 2012. The nomcom will

be collecting requirements from the community, as well as talking to

candidates and to community members about candidates. There will be

regularly scheduled conference calls to ensure progress. Thus, being a

nomcom member does require some time commitment.



Please volunteer by sending an email to me before

11:59 pm EDT July 10, 2011 as follows:



To: sures=
h.krishnan@ericsson.com

Subject: Nomcom 2011-12 Volunteer



Please include the following information in the body of the mail:



Full Name: =A0// As you enter in the IETF Registration Form,

 =A0 =A0 =A0 =A0 =A0 =A0// First/Given name followed by Last/Family Name


Current Primary Affiliation: // typically what goes in the Company

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // field in the IE=
TF Registration Form



Email Address(es): // all email addresses used to Register for the

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // past 5 IETF meetings

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // Please designate a Preferred email =
address for

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // contact if there is more than one e=
mail address



Telephone number: =A0// With country code (for confirmation if selected)


Please expect an email response from me within 3 business days stating

whether or not you are qualified. =A0If you do not receive a response in
this timeframe, please re-send your email with the tag "RESEND:" =
added

to the subject line.



If you are not yet sure you would like to volunteer, please consider

that Nomcom members play a very important role in shaping the

leadership of the IETF. =A0Ensuring the leadership of the IETF is fair

and balanced and comprised of those who can lead the IETF in the right

direction is an important responsibility that rests on the IETF

participants at large. Volunteering for the Nomcom is a good way of

contributing in that direction.



I will be publishing a more detailed target timetable, as well as

details of the randomness seeds to be used for the RFC 3797 selection

process within the next few days.



Thank you in advance for your participation.



Suresh Krishnan

Nomcom Chair 2011-2012

Email: nomcom-ch=
air@ietf.org, suresh.krishnan@ericsson.com



_______________________________________________

IETF-Announce mailing list

IETF-Announce@i=
etf.org

https://www.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________

Ietf mailing list

Ietf@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/ietf





--20cf307f336ce3850c04a67b6928--

From wangdanhua@huawei.com  Wed Jun 29 20:06:50 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2709711E80A3; Wed, 29 Jun 2011 20:06:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GS1B546BE37; Wed, 29 Jun 2011 20:06:48 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id DA0C711E8083; Wed, 29 Jun 2011 20:06:47 -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 <0LNL007VF1XR0Z@szxga05-in.huawei.com>; Thu, 30 Jun 2011 11:05:52 +0800 (CST)
Received: from szxrg01-dlp.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 <0LNL003EW1XR1X@szxga05-in.huawei.com>; Thu, 30 Jun 2011 11:05:51 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml202-edg.china.huawei.com) ([172.24.2.119])	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACE21556; Thu, 30 Jun 2011 11:05:43 +0800 (CST)
Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 30 Jun 2011 11:05:33 +0800
Received: from SZXEML504-MBX.china.huawei.com ([169.254.8.3]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Thu, 30 Jun 2011 11:05:42 +0800
Date: Thu, 30 Jun 2011 03:04:45 +0000
From: wangdanhua 
X-Originating-IP: [10.138.41.96]
To: "opsawg@ietf.org" , "tsvwg@ietf.org" , "dispatch@ietf.org" 
Message-id: 
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_BSfEl/DYdM2SDEFKzFNi0w)"
Content-language: zh-CN
Accept-Language: zh-CN, en-US
Thread-topic: Looking forward to your comments: Survey and Gap Analysis for Policies and Dynamic Information Migration in Data Center
Thread-index: AcwvxII6NIOr4KEqT7e/9oY69KijZAAA/D3AAGJst3ABYAr98A==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Thu, 30 Jun 2011 07:26:48 -0700
Subject: [dispatch] Looking forward to your comments: Survey and Gap Analysis for Policies and Dynamic Information Migration in Data Center
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2011 03:06:50 -0000

--Boundary_(ID_BSfEl/DYdM2SDEFKzFNi0w)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable

Hi all,

A few days ago, we sent a draft considering "policies and dynamic informati=
on migration in DC" to OPSAWG, the draft ID is "draft-gu-opsa-policies-migr=
ation-00" and its URL is http://datatracker.ietf.org/doc/draft-gu-opsa-poli=
cies-migration/ . Based on this problem statement draft as well as the disc=
ussion at the 80th IETF conference, we also performed a gap analysis betwee=
n dynamic information migration (DIM) requirements and the most related IET=
F works. We sent a gap analysis draft to the OPSAWG, here is the URL  http:=
//datatracker.ietf.org/doc/draft-wang-opsawg-policies-migration-gap-analysi=
s/ . Following is the abstract of this draft. We sincerely hope that you wo=
uld give your valuable comment or options if you are interest in this draft=
.

With the virtualization of Data Center, the number of VM explodes. VM can p=
lay different roles in Data Center, such as end-host, server, firewall, and=
 so on. Also, VM can be migrated to any places within Data Center, even to =
another Data Center. Since running services shouldn't be significantly inte=
rrupted while VM migrates, VM related policies and dynamic information gene=
rated by any devices must be transferred to destination devices during a pr=
oper short period. [I.D-gu-opsa-policies-migration-00] has introduced more =
detail problem statement and corresponding considerations. We wish we could=
 benefit from existing work to realize accurate dynamic information migrati=
on (DIM).  Therefore, we engaged in the investigation of related IETF works=
 right after general requirements of DIM are defined.  Since the solution f=
or DIM has not been decided yet, and the author can envision several kinds =
of solution, e.g. centralized or distributed.  It's unrealistic to enumerat=
e all the related works for an uncertain solution.  So, in this draft, only=
 the most related IETF work, MIDCOM protocol, has been evaluated to find ou=
t whether it can fully support DIM or which characteristics can be reused i=
n DIM. The author would like analyze other related IETF works when the WG m=
ake further decision on DIM solution.

Following a short description of general DIM requirements, this draft prese=
nts a brief survey of MIDCOM protocol, and then lists the gap between MIDCO=
M and DIM requirements.  The final section presents possible working scope =
on the topic of DIM in IETF.


Best Regards
Danhua Wang
HuaWei Technology Co. Ltd.
Nanjing, China

--Boundary_(ID_BSfEl/DYdM2SDEFKzFNi0w)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT











Hi all,


 


A few days ago, we sent a draft considering “policies and dynamic information migration in DC” to OPSAWG, the
 draft ID is “draft-gu-opsa-policies-migration-00” and its URL is
http://datatracker.ietf.org/doc/draft-gu-opsa-policies-migration/ . Based on this problem statement draft as well as the discussion at the 80th IETF conference, we also performed
 a gap analysis between dynamic information migration (DIM) requirements and the most related IETF works. We sent a gap analysis draft to the OPSAWG, here is the
URL  http://datatracker.ietf.org/doc/draft-wang-opsawg-policies-migration-gap-analysis/ . Following is the abstract of this draft.
 We sincerely hope that you would give your valuable comment or options if you are interest in this draft.


 


With the virtualization of Data Center, the number of VM explodes. VM can play different roles in Data Center, such as end-host,
 server, firewall, and so on. Also, VM can be migrated to any places within Data Center, even to another Data Center. Since running services shouldn't be significantly interrupted while VM migrates, VM related policies and dynamic information generated by any
 devices must be transferred to destination devices during a proper short period. [I.D-gu-opsa-policies-migration-00] has introduced more detail problem statement and corresponding considerations. We wish we could benefit from existing work to realize accurate
 dynamic information migration (DIM).  Therefore, we engaged in the investigation of related IETF works right after general requirements of DIM are defined.  Since the solution for DIM has not been decided yet, and the author can envision several kinds of solution,
 e.g. centralized or distributed.  It's unrealistic to enumerate all the related works for an uncertain solution.  So, in this draft, only the most related IETF work, MIDCOM protocol, has been evaluated to find out whether it can fully support DIM or which
 characteristics can be reused in DIM. The author would like analyze other related IETF works when the WG make further decision on DIM solution.


 


Following a short description of general DIM requirements, this draft presents a brief survey of MIDCOM protocol, and then lists
 the gap between MIDCOM and DIM requirements.  The final section presents possible working scope on the topic of DIM in IETF.


 


 


Best Regards


Danhua Wang


HuaWei Technology Co. Ltd.


Nanjing, China






--Boundary_(ID_BSfEl/DYdM2SDEFKzFNi0w)--

From dworley@avaya.com  Thu Jun 30 07:45:58 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC4311E8078 for ; Thu, 30 Jun 2011 07:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.166
X-Spam-Level: 
X-Spam-Status: No, score=-103.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 682akG7l4maD for ; Thu, 30 Jun 2011 07:45:58 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id D590E11E8075 for ; Thu, 30 Jun 2011 07:45:57 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EANWKDE6HCzI1/2dsb2JhbABSp1V3rH8Cmy+GMQSXQos3
X-IronPort-AV: E=Sophos;i="4.65,450,1304308800"; d="scan'208";a="254211944"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 30 Jun 2011 10:45:53 -0400
Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 30 Jun 2011 10:39:16 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Thu, 30 Jun 2011 10:45:51 -0400
From: "Worley, Dale R (Dale)" 
To: wangdanhua , "dispatch@ietf.org" 
Date: Thu, 30 Jun 2011 10:45:15 -0400
Thread-Topic: [dispatch] Looking forward to your comments: Survey and Gap Analysis for Policies and Dynamic Information Migration in Data Center
Thread-Index: AcwvxII6NIOr4KEqT7e/9oY69KijZAAA/D3AAGJst3ABYAr98AAYgFFk
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dispatch] Looking forward to your comments: Survey and Gap Analysis for Policies and Dynamic Information Migration in Data Center
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2011 14:45:58 -0000

Since SIP is not mentioned in either of these drafts, why are you sending t=
his message to the Dispatch working group?

Dale