Document Action: 'Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks' to Experimental RFC (draft-ash-gcac-algorithm-spec-04.txt)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The IESG has approved the following document:
- 'Generic Connection Admission Control (GCAC) Algorithm Specification
   for IP/MPLS Networks'
  (draft-ash-gcac-algorithm-spec-04.txt) as an Experimental RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Adrian Farrel.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ash-gcac-algorithm-spec/




Technical Summary

This document presents a generic connection admission control (GCAC) 
reference model and algorithm for IP/MPLS-based networks. Service provider 
(SP) IP/MPLS networks need an MPLS GCAC mechanism, for example, 
to reject voice over Internet Protocol (VoIP) calls when additional calls 
would adversely affect calls already in progress.


Working Group Summary

This document is being advanced as AD Sponsored.

This document was raised on the MPLS list but attracted no attention despite 
pleas from the authors for review and comment. The document is relevant to 
the WG, but is not disruptive to existing deployments nor competitive with 
existing or planned working group work.

There is no specific MPLS charter item to cover this I-D, because the level of 
interest in the working group (as gauged by mailing-list discussion) was minimal, 
and because this is not a protocol specification (it is an experimental algortihm) 
the MPLS chairs and AD agree that this does not need to be run through the 
working group. Nevertheless, this is being progressed as an IETF document 
because of its strong relevance to the MPLS working group.

The IETF last call was specifically notified to the MPLS and CCAMP working 
groups to encourage comments from that specific community.


Document Quality

This document is experimental. The objective is to place the algorithm in public 
view and encourage experimentation.

Personnel

   Young Lee (leeyoung@huawei.com) is the Document Shepherd
   Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD

RFC Editor Note

Section 4 paragraph 2 bullet list

ADD to the end of the list
   - [RFC5069] identifies a number of security threats against emergency
     call marking and mapping.  Section 6 of [RFC5069] lists security
     requirements to counter these threats, and those requirements 
     should be followed by implementaitons of this document.
 
   - The security requirements listed in Section 11 of [RFC4412] should
     be followed.  These requirements apply to use of the Communications 
     Resource Priority Header for the Session Initiation Protocol (SIP),
     and concern aspects of authentication and aurthorization,
     confidentiality and privacy requirements, protection against
     denial-of-service attacks, and anonymity.
END

---

Section 6

ADD at end of section.
Finally, Robert Sparks' thorough review and helpful suggestions
are sincerely appreciated.
END

---

Section 8 Add new references in the correct order

ADD
   [RFC4412] Schulzrinne, H., Polk, J., "Communications Resource
             Priority for the Session Initiation Protocol (SIP)", 
             RFC 4412, February 2006.

   [RFC5069] Taylor, T., et al., "Security Threats and Requirements for
             Emergency Call Marking and Mapping", RFC 5069, January
             2008.
END
_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux