「Transport Level Marking」 IE のタイプは、以下の図に示すようにエンコードされています。これは、downlink transport-level marking の DSCP 値を示しています。

Type-of-Service（ToS）または Traffic Class のエンコーディングは、OctetString として 2 つのオクテット形式で実行されます。最初のオクテットには、[IPv4 Type-of-Service] フィールドまたは [IPv6 Traffic-Class] フィールドの DSCP 値が含まれ、2 番目のオクテットには、0xFCに設定されてる [ToS/Traffic Class] マスクフィールドが含まれます。

「Transport Level Marking Options」 IE のタイプは、以下の図に示すようにエンコードされています。ダウンリンクトランスポート レベル マーキングの DSCP は、内部パケットからコピーされます。

Copy-Inner および Copy-Outer フラグは、オクテット 5 のビット 0 とビット 1 に存在します。ISP から受信するパケットには外部ヘッダーが存在しないため、ダウンリンクパケットには Copy-Outer フラグが使用されません。Copy-Inner フラグが存在する場合、UPF は内部パケットの DSCP 値を使用してトランスポートレベルの IP ヘッダーをマークします。

次の図に示すように、「Inner Packet Marking」IE タイプがエンコードされます。ダウンリンクの Inner Packet Marking の DSCP 値を示します。

ToS/通信クラスのエンコーディングは、OctetString として 2 つのオクテットの形式で実行されます。最初のオクテットには IPv4 ToS または IPv6 Traffic Class フィールドの DSCP 値が含まれ、2 番目のオクテットには ToS/Traffic Class マスクフィールドが含まれます。このフィールドは、0xFC に設定されています。

注：

• ユーザープレーンパケットの IP ヘッダー内の元の ECN ビットは、Transport Level Marking または Inner Packet Marking の適用後は変更されません。

• 「Transport Level Marking」IE、「Inner Packet Marking」IE または両方の IE が、アップリンク FAR に関連付けられている場合、次のリリースがアップリンクパケットマーキングに適用されます。

  • 「Transport Level Marking」IE または「Inner Packet Marking」IE が存在する場合、その DSCP 値が使用されます。

  • 「Transport Level Marking」IE および「Inner Packet Marking」IE の両方が存在する場合、アップリンクパケットマーキングには、「Transport Level Marking」IEからの値が使用されます。

リダイレクト情報は、次のようにエンコードされます。

リダイレクトアドレスのタイプを示す「Redirect Address Type」：

「リダイレクト サーバー アドレス長」は、「リダイレクト サーバー アドレス」の長さを示します。「リダイレクトサーバーアドレス」は、UTF8String フォーマットでエンコードされており、エンドユーザーと接続するリダイレクトサーバー（例：HTTP リダイレクトサーバー、SIP サーバー）のアドレスが含まれます。

Important

このリリースでは、FAR が クォータ期限切れの URR と関連付けられている場合に、ダイナミックルールに対して、リダイレクトアドレスタイプ URL がサポートされます。

現在のフレームワークでは、プラグイン到達時に、フロー内のすべてのパケットに対してディープ パケット インスペクション（DPI）が実行されます。DPI は、パケットを分析し、確定的なパターンを抽出することによって実行されます。DPI は順番に実行され、アプリケーションの検出とそのサブタイプの分類を行います。プラグインは、DPI 後のフローを除外します。フローは検出後にオフロードされます。QUIC IETF の一部として、初回の QUIC ハンドシェイクパケット（Client Hello/Server Hello）はネットワーク上で暗号化されます。したがって、アプリケーションの検出に使用できる確定的なパターンはありません。p2p プラグインによる、検出用 SNI（Server Name Indication）の復号と取得が新たにサポートされるようになりました。

QUIC IETF 復号を有効または無効にするには、次の設定を使用します。

configure 
   active-charging service acs_service_name 
      p2p-detection debug-param protocol-param p2p_quic_ietf_decrypt 1 
      end 

（注）	デフォルトでは、CLI は無効になっており、TLS 復号によるパフォーマンスへの影響は最小限です。 ランタイム変更の構成は、既存のフローに影響しません。変更は、新しいフローにのみ適用されます。

show user-plane-service statistics analyzer name p2p

この show CLI コマンドを使用して、QUIC とアプリケーションに関して分析するパケットを判断します。

Event Data Records（EDR）は、システム管理ユーザーによるコンテンツ情報、形式、および生成トリガーの構成をサポートする、使用状況レコードです。

フローが終了すると、UPF は終了したフローの詳細情報を使用して EDR を生成します。

EDR は、フロー終了時にユーザープレーンから生成されます。コールセットアップとコール変更中、EDR 生成に必要なすべてのコール固有属性は、Sx Establishment/Modification 要求メッセージの 「Subscriber Params」IE の一環として、SMF から UPF に送信されます。

フローの終了時に、VPP から課金カウンタが取得されます。EDR 形式の設定で設定されたすべてのコールレベル属性は、課金やボリュームカウンタの属性とともに CDRMOD proclet に送信されます。この proclet により、該当レコードがファイルまたはディスクに書き込まれ、設定された外部サーバーに転送されます。

TCP Fast Open

TCP Fast Open（TFO）は、2 つのエンドポイント間の連続する TCP 接続をより迅速に開始するための拡張機能です。そのためにこの機能では、クライアントに保存され、サーバーとの初回接続時に設定される暗号化 Cookie である TFO Cookie（TCP オプション）を使用します。クライアントが再接続する際、認証のために初回 SYN パケットとともに TFO Cookie データも送信します。認証が成功すると、サーバーは、3 ウェイハンドシェイクの最後の ACK パケットを受信する前であっても、クライアントへのデータ送信を開始できます。このため、EDR の TCP フローの制御パケット間の時間差を計算して記録するために、次のパケット間の差が記録されます。

• SYN および SYN-ACK パケット

• SYN-ACK および ACK パケット

EDR 内の情報をキャプチャするために追加されるルール変数の詳細については、「その他の TCP フィールドを構成する」項を参照してください。

トランザクション完了 EDR

HTTP トランザクションが完了すると、HTTP EDR に対してTransaction Complete EDR が生成されます。完了すると、VPP から課金カウンタがフェッチされます。EDR 形式の設定で設定されたすべてのコールレベル属性は、課金やボリュームカウンタの属性とともに CDRMOD proclet に送信されます。この proclet により、該当レコードがファイルまたはディスクに書き込まれ、設定された外部サーバーに転送されます。

次の EDR 属性がサポートされています。

• sn-start-time

• sn-end-time

• sn-start-time format MM/DD/YYYY-HH:MM:SS:sss

• sn-end-time format MM/DD/YYYY-HH:MM:SS:sss

• radius-calling-station-id

• radius-called-station-id

• bearer 3gpp imsi

• bearer 3gpp imei

• bearer 3gpp rat-type

• bearer 3gpp user-location-information

• ip subscriber-ip-address

• ip dst-address

• sn-ruledef-name

• sn-subscriber-port

• sn-server-port

• sn-app-protocol

• sn-volume-amt ip bytes uplink

• sn-volume-amt ip bytes downlink

• sn-flow-start-time format seconds

• sn-flow-end-time format seconds

• sn-volume-amt ip pkts uplink

• sn-volume-amt ip pkts downlink

• sn-direction

• traffic-type

• p2p protocol

• p2p app-identifier tls-cname

• p2p app-identifier tls-sni

• p2p app-identifier quic-sni

• bearer 3gpp sgsn-address

• sn-rulebase

• sn-charging-action

• flow tethered-ip-ttl

• flow ttl

• flow ip-control-param

• bearer qci

• tcp flag

• ip server-ip-address

• sn-flow-id

• sn-closure-reason

• sn-duration

• ip src-address

• IP プロトコル

• sn-charge-volume ip bytes uplink

• sn-charge-volume ip bytes downlink

次の HTTP EDR 属性がサポートされています。

• http url length 2000

• http request method

• http content type

• http user-agent length 255

• http reply code

• http referer

• http host

• http cookie

• http header-length

• transaction-uplink-bytes

• transaction-downlink-bytes

次の DNS EDR 属性がサポートされています。

• dns answer-ip-list

• dns answer-name

• dns previous-state

• dns query-name

• dns query-type

• dns return-code

• dns state

• dns tid

データの停滞を特定する EDR 属性

EDR は、データ停滞の問題を特定するために、次の属性をサポートしています。

• sn-last-uplink-pkt-time

• sn-last-downlink-pkt-time

アップリンクまたはダウンリンク報告の最後のパケットと sn-end time （フローリリース時間）間で平均差が大きい場合、これは、データの停滞を示しています。

これらの EDR 変数は、制御パケット（FIN/RST/FIN-ACK/TCP TEAR DOWN ACK）のパケット時間はキャプチャしません。これらのパケットのパケット時間は、sn-end time を使用してセッションマネージャでキャプチャされます。

オフロードされたフローの場合、属性 sn-last-uplink-pkt-time と sn-last-downlink-pkt-time は、fastpath を通過するパケットに対して更新されます。

UPF 2.0のファイアウォール機能は、サブスクライバ通信を検査し、サブスクライバセッションの IP セッションベースのアクセスコントロールｗｐ実行して、悪意のあるセキュリティ攻撃からサブスクリプションを保護します。UPF 2.0 は、サブスクライバフローをドロップするか、TCP タイムアウトの期限切れ時にリセットを送信する TCP アイドル タイムアウト アクションをサポートします。

ファイアウォールの設定により、システムはサブスクライバ データ セッションの各パケットを検査できます。また、セキュリティ脅威を評価し、アップリンクおよびダウンリンクトラフィックに設定されたポリシーを適用します。ファイアウォールは、フローレベルごとおよびパケットごとの検証をサポートします。

ファイアウォール機能は、次の機能をサポートしています。

• DoS および DDoS 攻撃からの保護

• アプリケーションレベル ゲートウェイ

• ステートフル パケット インスペクションおよびフィルタリング

• ステートレス パケット インスペクションおよびフィルタリング

• SNMP のしきい値設定

ファイアウォール構成は、UPF のアクティブな課金構成で使用できます。

• Access-Ruledefs

• Firewall-NAT Policy

この項では、この機能をサポートする show コマンドとその出力について説明します。

show config active-charging service name acs verbose

fw-and-nat policy SFW_NAT_TEST
      no firewall dos-protection source-router
      no firewall dos-protection winnuke
      no firewall dos-protection mime-flood
      no firewall dos-protection ftp-bounce
      no firewall dos-protection ip-unaligned-timestamp
      no firewall dos-protection tcp-window-containment
      no firewall dos-protection teardrop
      no firewall dos-protection flooding udp
      no firewall dos-protection flooding icmp
      no firewall dos-protection flooding tcp-syn
      no firewall dos-protection port-scan
      no firewall dos-protection ipv6-extension-hdrs
      no firewall dos-protection ipv6-hop-by-hop
      no firewall dos-protection ipv6-hop-by-hop router-alert
      no firewall dos-protection ipv6-hop-by-hop jumbo-payload
      no firewall dos-protection ipv6-hop-by-hop invalid-options
      no firewall dos-protection ipv6-hop-by-hop unknown-options
      no firewall dos-protection ipv6-dst-options
      no firewall dos-protection ipv6-dst-options invalid-options
      no firewall dos-protection ipv6-dst-options unknown-options
      no firewall dos-protection ipv6-frag-hdr nested-fragmentation
      no firewall dos-protection ip-sweep tcp-syn
      no firewall dos-protection ip-sweep udp
      no firewall dos-protection ip-sweep icmp
      firewall max-ip-packet-size 65535 protocol icmp
      firewall max-ip-packet-size 65535 protocol non-icmp
      firewall flooding protocol icmp packet limit 1000
      firewall flooding protocol udp packet limit 1000
      firewall flooding protocol tcp-syn packet limit 1000
      firewall flooding sampling-interval 1
      firewall tcp-syn-flood-intercept mode none
      firewall tcp-syn-flood-intercept watch-timeout 30
      firewall mime-flood http-headers-limit 16
      firewall mime-flood max-http-header-field-size 4096
      no firewall icmp-destination-unreachable-message-threshold
      access-rule no-ruledef-matches uplink action permit
      access-rule no-ruledef-matches downlink action deny
      firewall tcp-idle-timeout-action reset
      no firewall tcp-reset-message-threshold
      firewall tcp-syn-with-ecn-cwr permit
      firewall malformed-packets drop
      firewall ip-reassembly-failure drop
      no firewall validate-ip-options
      firewall tcp-options-error permit
      firewall icmp-echo-id-zero permit
      firewall icmp-checksum-error drop
      firewall tcp-checksum-error drop
      firewall udp-checksum-error drop
      firewall tcp-fsm first-packet-non-syn drop
      firewall icmp-fsm
      firewall policy ipv4-and-ipv6
      firewall tcp-partial-connection-timeout 30
      no nat policy
      no nat binding-record
      no nat pkts-drop edr-format
      no nat pkts-drop timeout 
      default nat suppress-aaa-update
      nat private-ip-flow-timeout 180
      nat check-point-info basic limit-flows 100
      nat check-point-info sip-alg
      nat check-point-info h323-alg
      nat max-chunk-per-realm single-ip
    #exit

アイドルタイムアウトフローをランダム化するには、次の構成を使用します。

configure 
active-charging service service_name 
   idle-timeout randomize-range range 
      { default | no } idle-timeout randomize-range 
         end 

注：

• idle timeout ：フローがアイドル状態を維持できる最大時間を秒単位で指定します。秒は、5 ～30 の整数で指定する必要があります。その後、フローはランダムな値に基づいて終了します。

• randomize-range ：期間を秒単位で指定します。適用されるアイドルタイムアウトは、フローごとに異なります。

  次に例を示します。

  idle-timeout randomize-range 20

  0 ～ 20 の整数のランダム番号が生成されます。この数値は、設定されたアイドルタイムアウト値に追加され、2 秒間のタイマー処理でフローがアイドルになったかどうかを確認します。設定されたアイドルタイムアウトが 60 秒に設定されている場合、各フローに適用される実際のタイムアウトは 60 + 20 秒の範囲でランダム化され、フローが段階的に削除されます。

• no ：アイドルタイムのランダム化を無効にします。このコマンドは、デフォルトでディセーブルになっています。

• default ：idle timeout randomization コマンドをを秒単位のデフォルト設定で構成します。秒は、0 ～30 の整数で指定する必要があります。デフォルト範囲は、0 ～30 秒です。

  たとえば、default idle-timeout randomize-range は、idle-timeout randomize-range 30 と同じです。

パケットの宛先 IP アドレスに基づいてパケットをアドレス再指定することで、道のゲートウェイ通信から既知または信頼されているゲートウェイにリダイレクトできます。これは、課金アクションでサーバーのアドレス再指定を構成することによって実装されます。

configure  
   active-charging service  acs_service_name  
      charging-action  charging_action_name  
         flow action readdress server ipv4_address/ipv6_address [ discard-on-failure ]  [ dns-proxy-bypass ]  [ port port_number [ discard-on-failure ] [ dns-proxy-bypass ] ]   
         end  

configure  
   active-charging service  acs_service_name  
      charging-action  charging_action_name  
         flow action readdress server-list server_list_name [ hierarchy ] [ round-robin ] [ dns-proxy-bypass ] [ discard-on-failure ]   
         end  

次に、server-list の構成例を示します。

readdress-server-list DRE
consecutive-failures 1
response-timeout 10000
server 209.165.200.225 port 53
server 209.165.200.226 port 53
server 2001:420:54fe::1019 port 53
server 2001:420:54fe::1039 port 53
server 2001:420:54fe::1049 port 53
server 2001:420:54fe::1059 port 53
server 209.165.201.30 port 8080
#exit

（注）	リストには、最大 10 のサーバーを構成でき、active-charging サービスには、最大 10 のリストを構成できます。

この項では、IP のアドレス再指定機能のサポートに使用可能な show CLI コマンドについて説明します。

clear user-plane-service readdress-server-list statistics all CLI を使用して、再アドレスサーバーリスト統計をクリアします。

show user-plane-service statistics charging-action all CLIを使用して、「再アドレスされた」カウンタを確認します。

UPF は、L7 アナライザの一部として DNSプロトコルをサポートします。

UPF 2.0 は、L7 アナライザの一部として FTP プロトコルをサポートします。

HTTP リクエストまたは HTTP 応答が完了すると、次の場合に、アップリンクまたはダウンリンクのデータパケットが、VPP にオフロードされます。

• コンテンツ長：ボリュームベースのオフロードは、GET や POST などのメソッドでサポートされます。チャンクエンコーディングによるデータ転送メカニズムを使用した HTTP フローは、HTTP で定義されているメソッドに関係なくオフロードされません。ストリームがコンテンツ長に基づいてオフロードされた場合、もう一方のストリームも、前者がオンロードされなくなるまでオフロードされます。

• CONNECT メソッド：フローが CONNECT にアップグレードされると、アップリンクとダウンリンクの両方のストリームがオフロードされるメソッドです。

• WebSocket メソッド：フローが WebSocket プロトコルとして分類されると、アップリンクとダウンリンクの両方のストリームがオフロードされます。

• ストリームは、次のいずれかの場合に再度、オンロードされます。

  • FIN パケットを受信した場合

  • コンテンツ長に違反している場合

  • PDN の更新

ヘッダー解析

rulebase に含まれる ruledef で定義されているヘッダーフィールドのみが解析されます。X-Header 機能の場合は、一部の HTTP ヘッダーフィールドと依存関係があるリダイレクトが設定されます。

HTTP 課金

• 完全なパケットは、課金されます。

• 部分的パケットは、完成時に課金されます。部分的パケットを完成させるパケットも、課金されます。

• 連結パケットは、課金されます。

• 遅延課金が有効になっている場合：制御パケットは、遅延課金 CLI 構成に応じて、アプリケーションベースのルールに対して課金されます。

• 応答ベースの課金が有効になっている場合：HTTP リクエストの応答を受信した後、その HTTP リクエストは応答ルールの CA に対して課金されます。

X-Header の解析とルール照合

x-header ルール行が含まれる ruledef が解析され、照合されます。

WebSocket

HTTP フローが WebSocket フローにアップグレードされた場合、HTTP GET リクエストの後のフローの後続のパケットの課金が関与します。

応答ベースの TRM

トランザクションルールの照合は、HTTP 応答パケットの受信後に行われます。

X-Header の挿入

HTTP リクエストへの X-Header の挿入がサポートされます。

UPF は、L7 アナライザの一部として HTTPS プロトコルをサポートします。

UPF 2.0 は、L7 アナライザの一部として RTP および RTSP プロトコルをサポートします。

Session Initiation Protocol は、IETF で定義されているシグナリングプロトコルです。Internet Protocol（IP）を介した音声やビデオ通話などの通信セッションの制御に広く使用されています。このプロトコルは、2 者（ユニキャスト）またはマルチパーティ（マルチキャスト）セッションの作成、変更、および終了に使用できます。セッションは、1 つまたは複数のメディアストリームで構成されます。

UPF 2.0 は、L7 アナライザの一部として SIP をサポートしています。

この項では、機能のモニタリングとトラブルシューティングのサポートに使用できる CLI コマンドに関する情報を提供します。

この機能を有効または無効にする場合の重要なポイントは次のとおりです。

• デフォルトでは、この機能はディセーブルになっています。

• この機能が IGNORE オプションとともに有効になっている場合、パケットは無効な送信元 IP アドレスに対して検証されます。対応する統計がそれに応じて増加します。ただし、IP が無効であるため、パケットに対するアクションはありません。

• この機能が DISCARD オプションとともに有効になっている場合、無効な送信元 IP アドレスを持つパケットは廃棄されます。対応する統計がそれに応じて増加します。