這份備忘錄提供了有關互聯網通信的信息，它并未涉及任何一種互聯網標準，可以自由傳播此備忘錄。
版權聲明
Copyright (C) The Internet Society (2000). All Rights Reserved.
摘要
現有的計費狀態方式屬性是用來支持在撥號終端提供強迫通道建立，這份文檔為現有的計費狀態方式定義了RADIUS計費屬性極其新值。
規范要求
在這份文檔中，要害詞“可以”，“必須”，“禁止”，“可選的”，“推薦的”，“應該”，“不應該”，等應該被解釋成[2]中的描述。
目錄
備忘錄 1
版權聲明 1
摘要 1
規范要求 2
1．介紹 2
2實施注重 3
3．新的計費狀態方式值 4
3．1．通道開始 4
3．2．通道停止 4
3．3通道拒絕 5
3．4通道鏈接開始 6
3．5通道鏈接停止 6
3．6通道鏈接拒絕 8
4．屬性 8
4．1計費通道連結 8
4．2 計費通道丟包 9
5．屬性表 10
6安全性考慮 11
7．參考文獻 11
8．感謝 11
9．作者地址 12
10．全部版權聲明 13
致謝 13

1．介紹
許多協議應用中都包括了撥號終端訪問。其中的一些，如提供通過互聯網的企業內部局域網的安全訪問，是定義成主動的通道建立：通道是在用戶為一個特定目的而發出請求時建立。另一些包括了強迫的通道建立：通道建立不需要任何的用戶響應，同時，不答應用戶做任何選擇，如同ISP的服務。
典型的，提供一項服務的ISP要為記賬，網絡計劃編制等收集數據。在撥號終端中收集有用數據的一種途徑是利用RADIUS計費[1]。利用RADIUS計費答應在一個中心位置收集有用數據而不是儲存在每一個NAS中。
為了收集通道建立數據，需要新的RADIUS屬性；這篇文檔定義了這些屬性。另外，提出了幾個關于計費狀態方式屬性的新值。對這些屬性在L2TP協議的應用，RFC2809中給出了具體的建議和例子。
2實施注重
強迫的通道建立可以是一個實體提供給另一個的服務包中的一部分。例如，一個公司可能和一個ISP簽訂協議通過強迫通道建立來為他的雇員提供遠程企業局域網訪問，在這種情況下嵌入RADIUS以及通道協議答應ISP和企業同步他們的計費活動事的雙方都收到一個用戶消費的紀錄。這給企業審計ISP的賬單提供了一種途徑。
在審核中，用戶名，計費通道連接，通道客戶端和通道服務器端的屬性通常被用來唯一的識別一個呼叫，答應NAS發出的計費請求與相應的通道服務器發出的請求保持一致。
在RADIUS計費應用于L2TP/PPTP通道建立時，呼叫序列號應該用在計費通道連接屬性中。在L2TP中，呼叫序列號是一個32位的域二在PPTP中，它是一個16位的域。在PPTP中，ip地址和呼叫序列號應該是唯一的，但不是必要的。另外，決定呼叫號碼的方法也不是確定的，這.....
需要注重的是，一個16位的呼叫序列號是不足以在一個擴展的時間周期從所有的呼叫中區分出一個給定的呼叫的。例如，假如呼叫序列號的分配是線性的，在查詢中的NAS有96個端口而且是持續忙的，平均的呼叫周期時20分鐘，這樣，一個16位的呼叫序列號將會在65536/（96*3呼叫/小時*24小時/天）=9.48天之內覆蓋。
3．新的計費狀態方式值
3．1．通道開始
值
9
描述
這個值可以被用來標志和另一個節點的通道建立。假如這個值被使用，下面的屬性應該也包含在計費請求包中：
用戶名（1）
NAS—IP地址（4）
計費延遲時間（41）
時間時間標簽（55）
通道類型（64）
通道媒體類型（65）
通道客戶端（66）
通道服務器端（67）
計費通道連接（68）
3．2．通道停止
值
10
描述
這個值可以被用來標志和另一個節點的通道消除。假如這個值被使用，下面的屬性應該也包含在計費請求包中：
用戶名（1）
NAS—IP地址（4）
計費延遲時間（41）
計費輸入字節（42）
計費輸出字節（43）
計費通話ID（44）
計費通話時間（46）
計費輸入包（47）
計費輸出包（48）
計費終止原因（49）
計費多話路ID（51）
事件時間標簽（55）
通道類型（64）
通道媒體類型（65）
通道客戶端（66）
通道服務器端（67）
計費通道連接（68）
機非通道丟包（86）
3．3通道拒絕
值
11
描述
這個值可以被用來標志和另一個節點的通道建立拒絕。假如這個值被使用，下面的屬性應該也包含在計費請求包中：
用戶名（1）
NAS—IP地址（4）
計費延遲時間（41）
計費終斷原因（49）
時間時間標簽（55）
通道類型（64）
通道媒體類型（65）
通道客戶端（66）
通道服務器端（67）
計費通道連接（68）
3．4通道鏈接開始
值
12
描述
這個值可以被用來標志一個通道鏈接的建立。只有一些通道類型（如L2TP）支持每通道多鏈接。這個屬性傾向于標志載一個有著多鏈接的通道內一個鏈接的建立。例如，假如一個強制的通道在生存期內要承載M個鏈接，那么2（M+1）RADIUS計費消息可能被發送：每一個消息代表在通道內的每一個鏈接的初始化和消除。只要一個單獨的鏈接能夠承載在一個給定的通道中（例如，通道模式下的第二個IP），這個屬性不需要包含在計費包中，因為通道開始屬性的存在會暗示（僅可能的）鏈接的初始化。
假如這個值被使用，下面的屬性也應該包含在計費請求包中：
用戶名（1）
NAS—IP地址（4）
NAS—端口（5）
計費延遲時間（41）
事件時間標簽（55）
通道類型（64）
通道媒體類型（65）
通道客戶端（66）
通道服務器端（67）
計費通道連接（68）
3．5通道鏈接停止
值
13
描述
這個值可以用來標志一個通道鏈接的結束。只有一些類型（如L2TP）支持每通道的多鏈接。例如，假如一個強迫的通道在他的生存起立要承載M個鏈接，那么2（M+1）個RADIUS機非消息可能會被發送：每一個標志一個通道結束的初始化。假如只有一個單獨的鏈接可以承載在一個給定通道上，這個屬性就不需要包含在計費包中，因為現有的通道停止屬性會暗示這個（僅可能的）鏈接的終止。
假如這個值被使用下面的屬性應該也包含在計費請求包中：
用戶名（1）
NAS—IP地址（4）
NAS端口（5）
計費延遲時間（41）
計費輸入字節（42）
計費輸出字節（43）
計費通話ID（44）
計費通話時間（46）
計費輸入包（47）
計費輸出包（48）
計費終止原因（49）
計費多話路ID（51）
事件時間標簽（55）
NAS端口類型（61）
通道類型（64）
通道媒體類型（65）
通道客戶端（66）
通道服務器端（67）
計費通道連接（68）
計費通道丟包（86）
3．6通道鏈接拒絕
值
14
描述
這個值可以用來標志在一個現存通道中建立一個新鏈接被拒絕。只有一些類型（如L2TP）支持每通道的多鏈接。只要一個單獨的鏈接可以承載在一個給定通道上（如在通道模式下的IPsec），這個屬性就不需要包含在計費包中，因為在這種情況下通道拒絕屬性有著同樣的意義。
假如這個值被使用下面的屬性應該也包含在計費請求包中：
用戶名（1）
NAS—IP地址（4）
NAS—端口（5）
計費延遲時間（41）
計費終止原因（49）
事件時間標簽（55）
通道類型（64）
通道媒體類型（65）
通道客戶端（66）
通道服務器端（67）
計費通道連接（68）
4．屬性
4．1計費通道連結
描述
這個屬性指出了分配給通道話路的標示符。它應該包含在計費請求包中，這個請求包包含了計費狀態類型屬性，包括開始值，結束值或任何上面描述的值。這個屬性，連同通道客戶端和通道服務器端屬性[3]，可以用來提供一個唯一的標識一個通道話路的手段來用于審核。
下面給出了計費通道連接格式的一個概要。這些域是從左向右傳輸。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
類型 長度 字符 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
類型
68，用于計費通道連接
長度
〉=3
字符
標識符的格式在字符域描述，他依靠于通道類型屬性[3]的值。例如，為了充分的標識一個L2TP通道連結，L2TP通道ID和主叫ID可能在這個域編碼。這個域嚴格的編碼是非獨立執行的。
4．2 計費通道丟包
描述
這個屬性指出在一個給定的鏈接上丟包的數目。它應該包含在計費請求包中，這個包包括了計費狀態類型屬性，包括通道鏈接停止值。
下面給出了計費通道丟包屬性格式的一個概要。這些域是從左向右傳輸的。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
類型 長度 丟包
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
丟包 (計數)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
類型
86，用于計費通道丟包
長度
6
丟包
丟包域是4個字節長度域，表示在鏈接上丟失的包數。
5．屬性表
下面的表給出一個向導，其中的屬性可以在計費請求包中找到。在計費響應包中應該沒有通道屬性。

請求 # 屬性
0-1 64 通道類型
0-1 65 通道媒體類型
0-1 66 通道客戶端
0-1 67 通道服務器端
0-1 68 計費通道鏈接
0 69 通道密碼
0-1 81 通道獨立組ID
0-1 82 通道分配ID
0 83 通道優先選擇
0-1 86 計費通道丟包

下面的標定義了上表部分含義。
0 這個屬性禁止在包中出現。
0+ 這個屬性的0或更多的情況可以在包中出現。
0--1 這個屬性的0或1的情況可以在包中出現。

6安全性考慮
通過偵聽RADIUS計費包，可能給一個偷聽者機會進行被動的通道鏈接分析。
7．參考文獻

[1] Rigney, C., "RADIUS Accounting", RFC2866, June 2000.

[2] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.

[3] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
I. Goyret, "RADIUS Attributes for Tunnel PRotocol Support", RFC
2868, June 2000.

[4] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC2661,
August 1999.

[5] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and
G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC2637,
July 1999.
8．感謝
感謝Aydin Edguer, Ly Loi, Matt Holdrege and Gurdeep Singh Pall輸入校對。
9．作者地址
Glen Zorn
Cisco Systems, Inc.
500 108th Avenue N.E., Suite 500
Bellevue, Washington 98004
USA

Phone: +1 425 438 8218
FAX: +1 425 438 1848
EMail: gwz@cisco.com

Dave Mitton
Nortel Networks
880 Technology Park Drive
Billerica, MA 01821

Phone: +1 978 288 4570
Fax: +1 978 288 3030
EMail: dmitton@nortelnetworks.com

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052

Phone: +1 425 936 6605
Fax: +1 425 936 7329
EMail: aboba@internaut.com
10．全部版權聲明
Copyright (C) The Internet Society (2000). All Rights Reserved.
這份文檔極其譯文可以拷貝及提供給他人，對它的延伸，解釋，或幫助它的執行，都可以部分或全部的預備、拷貝、印刷出版以及傳播，沒有任何的限制，只要以上的版權聲明和這一段話包括在這些拷貝及延伸上。可是，這個文檔本身不可以以任何形式修改，如去掉版權注重或者是互聯網組織的參考書目，或是其他組織的參考文獻，除非是發展互聯網標準目的需要，在這種情況下，互聯網標準的處理程序中的版權說明必須要有，或者按照要求把它翻譯成英語以外的語言。
以上有限制的給以許可是永久的而且不能被互聯網組織及其繼續者撤銷或分配。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
致謝
Funding for the RFC