From akatlas@gmail.com Tue May 3 09:32:06 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A65CE087A for ; Tue, 3 May 2011 09:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, 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 dbI9QKThgcld for ; Tue, 3 May 2011 09:32:05 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2171DE086A for ; Tue, 3 May 2011 09:32:03 -0700 (PDT) Received: by iwn39 with SMTP id 39so245593iwn.31 for ; Tue, 03 May 2011 09:32:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=NHeuAwrBXVDwB0rGpvbQDN/hRqTJNbMp4wY+Cq5BLPM=; b=hnvOm6BhRR9CJNwACZGp9QypnaOFYAbT0Pk76xnsbPJ8lBMfcwLvVLzrbeN/2G4ty7 iYQC3RXRCQZjeywUnREMRKP+y5XGibvXylMqu3O1+K99Wvp2UCiwcZOnIhSjI83HXd6E yV/66ZHLMCQa+KOseOwmdyIWet8cOQlHo6mR8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=bzriEUpTY4XRJG+YGNBPR5lTvVxvaacbEwGJblDjAnblIOdm0OMZ/Zd7YiAILbeRuc 4I/rEQSef2eGEnsMbzN2djmM6ycVKg/SKqNJtDSvg662Pnb7OqLntGdFJQ6AMgVxciYS 6ASLQCqSBW/RBRxU93Sq4rADE+R1kHGAwiJls= MIME-Version: 1.0 Received: by 10.42.115.200 with SMTP id l8mr42386icq.284.1304440322709; Tue, 03 May 2011 09:32:02 -0700 (PDT) Received: by 10.42.3.9 with HTTP; Tue, 3 May 2011 09:32:02 -0700 (PDT) Date: Tue, 3 May 2011 09:32:02 -0700 Message-ID: Subject: IETF 80 minutes available From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 16:32:06 -0000 Thanks to Joel Halpern for taking minutes. The minutes are below. Alia =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Notes for RTGWG Session =96 Monday, March 28, 2011 1300 CEDT =96 Prague Agenda Bashing & Current Draft Statuses - Alia Atlas Announcement of note well. Review of status presented LFA Applicability - draft-ietf-rtgwg-lfa-applicability - Clarence Filsfils Described differences in latest version =96 editorial nits and better explanation of failure effects. Added explanation of capacity planning with LFA. Document will go to WG last call after IETF. Multicast Only Fast Reroute - draft-karan-mofrr - Clarence Filsfils Problem: fast recovery from network outages (<50ms). Aimed at being an easy solution for common cases; not applicable to all cases. No planning for extra bandwidth; no IGP convergence dependency. Discussion of application to Two-Plane. Network designs. Q from John Scudder =96 Draft says intended status is informational. Is that intended? Author agrees to accept chairs=92 advice on intended status. Arun asks were the work belongs? Here, PIM? Clarence responds suggesting that it belongs here since there are no changes to the protocol changes to PIM. Chairs agree to talk to other chairs and ADs about the correct location for the work. Composite Link Framework - draft-so-yong-rtgwg-cl-framework-03 - Ning So Changes made to align with the requirements draft evolution. Signaling extensions to LDP support to address problems found by discuss= ion Added section on Management plane impact John Scudder asked for objections, noting that given the requirements work already done by the WG, this is likely to be adopted as a working group document. Review of the scope of the protocol extensions needed to support this work. The presenter noted that there are many small impacts on many protocols. Composite Link Discussion Curtis Villamizer suggested taking an inventory of existing mechanisms to address the needs. Lou Berger suggested that CCAMP will need to discuss the protocol changes once there are actual drafts with proposals. John Scudder pointed out that the common approach is to present such material twice, once in RTGWG for the collective work and once in the protocol WG. Acee Lindem agreeing that more information is needed before it can be determined where to do the work. Agreement that Last call will probably need to be in multiple places. OSPF TE Express Path - draft-giacalone-ospf-te-express-path - Spencer Giaco= lone Driven by a need for low latency, very high grade SLA, network services. Financial data networks, for example. Traditional metric techniques are hard to use. Overview of solution: OSPF extensions to distribute performance informat= ion. The draft is aimed at TE, and aims at distributing average (steady state) values. Control plane specifics to ensure stability are important but separate. Discussion of details of encoding. Details of precision and general issues of extensibility and stability. Lou Berger raised another draft (delay-metric draft in ccamp) sthat should be compared, and maybe combined with this work. Wenhu Lu asked about how the information is used, in parciular whether this is driven by client requests, of more pushed from CSPF? If pushed, how does CSPF know whom to notify. Alia Atlas compared this to link failure notifications. Agreed that triggering has to be relevant to affected LSPs. Fast Notification Framework - draft-lu-fast-notification-framework - Wenhu = Lu Summary of changes presented. Text modified to clarify goals of work. Dicussion of open issues. Transport of Fast Notification Messages - draft-lu-fn-transport-00 - Jeff Tantsura Presentation of a generic mechanism to carry notifications needing rapid dissemination. Description of necessary properties; using a pair of redundant trees to meet goals. Two possible encapsulations mentioned. Description of authentication: per link or per area. IP Fast-Reroute with Fast Notification - draft-csaszar-ipfrr-fn-00 - Andras Csaszar Description of using fast notification to enable IP FRR with rapid response and good coverage. NS-2 had something like this (simplified) many years ago. Walk through of the behavior and its results. Including issues when only some nodes support the capability. Stewart Bryant (also Channeling Mike Shand): How does this differ from the earlier presented methods of remote fast-reroute? A rough answer was provided. Doesn=92t the presence of many legacy nodes cause serious micro-loops? Yes. This assumes that most of the nodes have been upgraded, and only a few are using old behavior. Debate of likely impact. How does this scale in terms of computation and FIB loading? Answer that the authors have some computations in the drafts. Hannes finds the idea appealing, wonders whether this should include support for ordered FIB update? Andras responded that with the fast path forwarding, the micro-loop issue is significantly decreased, so there may not be need for ordered FIB. Hannes pointed out the link up is still uncovered. (Mike Shand via Stewart) comments that FIB update time is what drives the micro-loop FIB ordering issues. Discussion ensued. Hannes asked about cancellation, for example with a micro-flap. General question raised / discussed as to whether this piece of the puzzle (fast propagation of notification) is important to solve? Definitional argument as to whether non-local repair can be local fast re-route. In particular, when the speed of light delay across the area is longer than the target response time, does this help? Network diameters in the range of 11 to 15 hops were in the data collected earlier, and need to be handled. Eric Osborne asked if this could be handled more generally with an OSPF fast flood LSA. John Scudder called for conversation on the mailing list, with the hope of either adopting or dispensing with this work by the next meeting. He asked for an executive summary to the mailing list. New Protocol for on-demand dynamic route optimizations between tunnel endpoints =96 draft-templin-intarea-vet-24, section 5.14 =96 Fred Templin This is work based on Internet area tunnel work. When one has many devices using a tunneled infrastructure, one can overload hub routers, or have very large number of routing adjacencies which are hard to handle. Outline of a set of (10) requirements. ICMP Router Redirects address something similar, but has serious drawbacks when checked against the requirements. So they have built a custom redirection solution: predirecti= on. The proposal handles asymmetry and legacy easily. Fred is hoping that the draft he will be submitting will be considered by the working group. Jeff asks about whether the NBMA can ensure transitive reachability. If the source being redirected can not send packets directly to the target to which it is being directed, how is this detected and coped with? History tells us this happens. From Internet-Drafts@ietf.org Wed May 4 09:30:11 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798BCE065F; Wed, 4 May 2011 09:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, 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 ja32h1pT38RW; Wed, 4 May 2011 09:30:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEAFAE07B2; Wed, 4 May 2011 09:30:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-rtgwg-lfa-applicability-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110504163010.3712.51706.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2011 09:30:10 -0700 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 16:30:11 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group Working Group of the IETF. Title : LFA applicability in SP networks Author(s) : C. Filsfils, et al. Filename : draft-ietf-rtgwg-lfa-applicability-02.txt Pages : 32 Date : 2011-05-04 In this draft, we analyze the applicability of LoopFree Alternates in both core and access parts of Service Provider networks. We provide design guides to favor their applicability where relevant, typically in the access part of the network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-lfa-applicability-02.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-rtgwg-lfa-applicability-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-04091755.I-D@ietf.org> --NextPart-- From wwwrun@ietfa.amsl.com Tue May 17 08:35:27 2011 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 5265CE073C; Tue, 17 May 2011 08:35:27 -0700 (PDT) To: azinin@cisco.com, dwfedyk@nortelnetworks.com, gchoudhury@att.com, bimhoff@planetspork.com, traveendra@huawei.com, chris@ipath.net From: IETF Secretariat Subject: IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 5286 Message-Id: <20110517153527.5265CE073C@ietfa.amsl.com> Date: Tue, 17 May 2011 08:35:27 -0700 (PDT) X-Mailman-Approved-At: Tue, 17 May 2011 09:01:57 -0700 Cc: azinin@cisco.com, housley@vigilsec.com, jgs@juniper.net, adrian@olddog.co.uk, stbryant@cisco.com, ipr-announce@ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 15:35:27 -0000 Dear Alex Zinin, Don Fedyk, G Choudhury, Brent Imhoff, Raveendra Torvi, Christian Martin: An IPR disclosure that pertains to your RFC entitled "Basic Specification for IP Fast Reroute: Loop-Free Alternates" (RFC5286) was submitted to the IETF Secretariat on 2011-05-17 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1557/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to RFC 5286." The IETF Secretariat From gash5107@yahoo.com Thu May 26 09:51:36 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171E8E0655 for ; Thu, 26 May 2011 09:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.188 X-Spam-Level: X-Spam-Status: No, score=-99.188 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 xP94T-yTdylF for ; Thu, 26 May 2011 09:51:30 -0700 (PDT) Received: from nm28-vm2.bullet.mail.ne1.yahoo.com (nm28-vm2.bullet.mail.ne1.yahoo.com [98.138.91.128]) by ietfa.amsl.com (Postfix) with SMTP id 91A26E0721 for ; Thu, 26 May 2011 09:51:30 -0700 (PDT) Received: from [98.138.90.53] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 26 May 2011 16:51:27 -0000 Received: from [98.138.89.252] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 26 May 2011 16:51:27 -0000 Received: from [127.0.0.1] by omp1044.mail.ne1.yahoo.com with NNFMP; 26 May 2011 16:51:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 373022.56895.bm@omp1044.mail.ne1.yahoo.com Received: (qmail 89745 invoked by uid 60001); 26 May 2011 16:51:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1306428687; bh=0RrhAV1LY1ilwDBuu8cfkPjSeCUM9OiBRd7+LlCRmCs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=mfcTk2oxIGs9ge6S3mcrQLyuwghEoxAQqRjdO59ZIUWzdg9s1E5tzL7hUMTwzf6t1ir4lsGda0iDErbjtVsGa4uVlsfDQHn6W9LZPwxj7f0mo+ry6PH1uEBq7kUEOeQ664Wkyvib19w4zvQ7xGV3eARYc7s1dz0btSG0gr/KDak= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=VXe/8OCEeG0KKkFTGb3DaZljx6gF893l/NZbHGrX5sShd4g4ujJo/1ecsBFc907kKr4fetqh+KRNcd5zdOU/sAVbqrpVHO9vr+z6Fg9B6Pgk27DrBXx0PKE95M5Bnzwcr62Nx2iX7ZfRCDxULqqYqm2jCKojgD/qLgfQ4pUBryc=; Message-ID: <285128.82087.qm@web125919.mail.ne1.yahoo.com> X-YMail-OSG: 8kV5gCYVM1mnhywaa9Ft4Xgv7PS54KaW84.aUc9dKm0G6zG 1lFPbUDX.TEdtRMJtUEun2axEhY.fPJqTigj6aRTZedffpkWU0JRKfpnrkFl bnmZj33hTjBMJQn2I4btzkgPLGvb8nuv5VXFI7rXWQTBpfnr_Dc5aDg.5nbW u0C44OAhfLRSof4rv0p.hiVQPauET3NpldfQiH9EQH7PR9ZpAKczXImMakbv 7PFFfn4Q5p0BWvFWZH40EVIfvwic3WP4rz_L8hO_E5rA7XDEYAE9jq_pXEAB s9BCbohMUVVu1oJsZIVdVuFHnO3_mFvClj7gflQHcbMHrGz65lHP6dgvo0vQ RGnHP6NpRgNVKKZBgikG2f51l5g-- Received: from [71.233.102.170] by web125919.mail.ne1.yahoo.com via HTTP; Thu, 26 May 2011 09:51:27 PDT X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.303096 Date: Thu, 26 May 2011 09:51:27 -0700 (PDT) From: Gerald Ash Subject: Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks To: rtgwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1626380600-1306428687=:82087" Cc: mpls@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 16:51:36 -0000 --0-1626380600-1306428687=:82087 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi, =A0 Adrian has suggested that the RTGWG and the MPLS WG review=A0the draft "Gen= eric Connection Admission Control (GCAC) Algorithm Specification for IP/MPL= S Networks", available=A0at =A0http://www.ietf.org/id/draft-ash-gcac-algori= thm-spec-00.txt=A0(abstract=A0below). The underlying goal of the work is to specify an optional GCAC algorithm fo= r IP/MPLS networks,=A0to be adopted and implemented by vendors and service = providers, that interoperates between vendor equipment and across multiple = service provider domains.=A0 This would be analogous to the PNNI GCAC that = was widely adopted and=A0helped promote=A0interoperability of ATM networks.= =A0 In addition, the approach: o=A0is=A0based on=A0CSPF, widely implemented by vendors o=A0does=A0NOT include aspects of CAC that might be considered vendor propr= ietary implementations, such as detailed path selection mechanisms o relies on=A0available standard mechanisms for MPLS based networks, such a= s RSVP, DSTE, PCE... =A0 Comments appreciated. =A0 Thanks, Jerry =A0 From: Internet-Drafts@ietf.org=A0 To: i-d-announce@ietf.org=A0 Reply-to: Internet-Drafts@ietf.org=A0 Subject: I-D ACTION:draft-ash-gcac-algorithm-spec-00.txt=A0 X-RSN: 1/0/935/34473/37870=A0 =A0 A New Internet-Draft is available from the on-line Internet-Drafts =A0 directories. =A0 Title : Generic Connection Admission Control (GCAC) Algorithm Specification= for IP/MPLS Networks=A0 Author(s) : G. Ash, D. McDysan=A0 Filename : draft-ash-gcac-algorithm-spec-00.txt=A0 Pages : 23=A0 Date : 2011-1-11=A0 =A0 This document presents a generic connection admission control (GCAC)=A0 reference model and algorithm for IP/MPLS-based networks. Service=A0 provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, for=A0 example, to reject voice over Internet Protocol (VoIP) calls when=A0 additional calls would adversely affect calls already in progress.=A0 =A0 Without MPLS GCAC, connections on congested links will suffer=A0 degraded quality. The MPLS GCAC algorithm can be optionally=A0 implemented in vendor equipment and deployed by service providers.=A0 MPLS GCAC interoperates between vendor equipment and across multiple=A0 service provider domains. The MPLS GCAC algorithm uses available=A0 standard mechanisms for MPLS based networks, such as RSVP, DSTE, PCE,=A0 NSIS, DiffServ, and OSPF. The MPLS GCAC algorithm does not include=A0 aspects of CAC that might be considered vendor proprietary=A0 implementations, such as detailed path selection mechanisms. MPLS=A0 GCAC functions are implemented in a distributed manner to deliver the=A0 objective QoS for specified QoS constraints. The source is able to=A0 compute a source route with high likelihood that MPLS GCAC via=A0 elements along the selected path will in fact admit the request.=A0 MPLS GCAC is applicable to any service or flow that must meet an=A0 objective QoS (delay, jitter, packet loss rate) for a specified=A0 quantity of traffic.=A0 =A0 A URL for this Internet-Draft is:=A0 http://www.ietf.org/internet-drafts/draft-ash-gcac-algorithm-spec-00.txt =A0 Internet-Drafts are also available by anonymous FTP at:=A0 ftp://ftp.ietf.org/internet-drafts/ =A0 Below is the data which will enable a MIME compliant mail reader=A0 implementation to automatically retrieve the ASCII version of the=A0 Internet-Draft.=A0 _______________________________________________=A0 I-D-Announce mailing list=A0 I-D-Announce@ietf.org=A0 https://www.ietf.org/mailman/listinfo/i-d-announce=A0 Internet-Draft directories: http://www.ietf.org/shadow.html=A0 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt=A0 =A0 *****=A0 Click below to download the attachment(s) in this message:=A0 Attachment: draft_ash_gcac_algorithm_spec_00= .txt (1K)=A0 --0-1626380600-1306428687=:82087 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
H= i,
 
Adrian has suggested that the RTGWG and the MPLS WG review the dr= aft "Generic http://www.ietf.org/id/draft-ash-gcac-algorithm-spec-00.txt=  (abstract below).
The underlying goal of the work is to specify an optional GCAC algorit= hm for IP/MPLS networks, to be adopted and implemented by vendors and = service providers, that interoperates between vendor equipment and across m= ultiple service provider domains.  This would be analogous to the PNNI= GCAC that was widely adopted and helped promote interoperability= of ATM networks.  In addition, the approach:
o is based on CSPF, widely implemented by vendors
o does NOT include aspects of CAC that might be considered v= endor proprietary implementations, such as detailed path selection mechanis= ms
o relies on available standard mechanisms for MPLS based networks= , such as RSVP, DSTE, PCE...
 
Comments appreciated.
 
Thanks,
Jerry
 
From: Internet-Drafts@ietf.org&nbs= p;
To: i-d-announce@ietf.org Reply-to: Internet-Drafts@ietf.org 
Subject: I-D ACTION:draft-ash= -gcac-algorithm-spec-00.txt 
X-RSN: 1/0/935/34473/37870 
&n= bsp;
A New Internet-Draft is available from the on-line Internet-Drafts =  
directories.
 
Title : Generic Connection Admission Co= ntrol (GCAC) Algorithm Specification for IP/MPLS Networks 
Author(s= ) : G. Ash, D. McDysan 
Filename : draft-ash-gcac-algorithm-spec-00= .txt 
Pages : 23 
Date : 2011-1-11 
 
This = document presents a generic connection admission control (GCAC) 
reference model and algo= rithm for IP/MPLS-based networks. Serv= ice 
provider (SP) IP/MPLS networks need an MPLS GCAC mechan= ism, for 
example, to reject voice over Internet Protocol (VoIP) ca= lls when 
additional calls would adversely affect calls already in = progress. 
 
Without MPLS GCAC, connections on congested li= nks will suffer 
degraded quality. The MPLS GCAC algorithm can be o= ptionally 
implemented in vendor equipment and deployed by service = providers. 
MPLS GCAC interoperates between vendor equipment and ac= ross multiple 
service provider domains. The MPLS GCAC algorithm us= es available 
standard mechanisms for MPLS based networks, such as = RSVP, DSTE, PCE, 
NSIS, DiffServ, and OSPF. The MPLS GCAC algorithm= does not include 
aspects of CAC that might be considered vendor p= roprietary 
implementations, such as detailed path selection mechanisms. MPLS 
GCAC functions are implemented in a distributed = manner to deliver the 
objective QoS for specified QoS constraints.= The source is able to 
compute a sour= ce route with high likelihood that MPLS GCAC via 
elements a= long the selected path will in fact admit the request. 
MPLS GCAC i= s applicable to any service or flow that must meet an 
objective Qo= S (delay, jitter, packet loss= rate) for a specified 
quantity of traffic. 
 =
A URL for this Internet-Draft is: 
http://www.ietf.= org/internet-drafts/draft-ash-gcac-algorithm-spec-00.txt
 
Internet-Drafts are also available by anonymous FTP at: = ;
ftp://ftp.ietf.org/internet-drafts/
 
Below is the data whi= ch will enable a MIME compliant mail reader 
implementation to auto= matically retrieve the ASCII version of the 
Internet-Draft. <= BR>_______________________________________________ 
I-D-Announce ma= iling list 
I-D-Announce@ietf.org 
https://www.ietf.org/mailman/listinfo/i-d-announc= e 
Internet-Draft directories: http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt 
 
***** 
Click below to download the attach= ment(s) in this message: 
<A HREF=3D"http://= www.ietf.org/ibin/c5i?mid=3D6&gid=3D0&rid=3D8&k1=3D935&file= =3Di-d-announce.37870.1.txt">Attachment: draft_ash_gcac_algor= ithm_spec_00.txt</A> (1K) 
--0-1626380600-1306428687=:82087--