Shootingfish:スクール

カテゴリ：スクール

• 顧客要件の調査、の手順(まとめ)(になってるんだろうか)
  [ 2007-03-15 20:34 ]
• 間違えた問題
  [ 2007-03-14 21:32 ]
• ﾈｯﾄﾜｰｸのｻｰﾋﾞｽﾚﾍﾞﾙの管理
  [ 2007-03-09 17:57 ]
• ﾈｯﾄﾜｰｸ管理の機能領域(課金管理･性能管理･機密管理)
  [ 2007-03-09 15:11 ]
• ﾈｯﾄﾜｰｸ管理用のﾌﾟﾛﾄｺﾙと機能の確認
  [ 2007-03-09 00:07 ]
• 音声ﾄﾗﾌｨｯｸ処理の概念によるｷｬﾊﾟｼﾃｨの計画
  [ 2007-03-08 20:43 ]
• 音声技術の要件の特定
  [ 2007-03-08 17:50 ]
• VoFR・VoATM
  [ 2007-03-08 16:58 ]
• 音声に関する問題/VoIP制御及び転送ﾌﾟﾛﾄｺﾙ
  [ 2007-03-08 16:57 ]
• 音声ｱｰｷﾃｸﾁｬの統合
  [ 2007-03-08 15:20 ]

顧客要件の調査、の手順(まとめ)(になってるんだろうか)

①組織目標
･競争力の強化
･ｺｽﾄ削減
･売上と利益の増加
･開発ｻｲｸﾙの短縮と生産性の向上
･顧客ｻﾎﾟｰﾄ改善と新規顧客ｻｰﾋﾞｽ提供
･情報ｲﾝﾌﾗの開放(皆で使えるように、って事)
―これから会社としてどう成長していくか、と言う部分。
　ﾈｯﾄﾜｰｸ云々より会社としてどういう方向に行くかって感じのもの。それをﾈｯﾄﾜｰｸでどう実現するか、という事か。

②組織上の制約
･予算
･人員
･ｽｹｼﾞｭｰﾙ
･ﾎﾟﾘｼｰ
―これは必須。丸ごと覚えたほうが楽かも。ﾎﾟﾘｼｰの中身は技術上の制約と悩むことも?

③ｱﾌﾟﾘｹｰｼｮﾝ
･ﾒｰﾙ
･ｸﾞﾙｰﾌﾟｳｪｱ
･音声ﾈｯﾄﾜｰｷﾝｸﾞ
･ﾌﾞﾗｳｻﾞ
･動画
･DB

④ｲﾝﾃﾘｼﾞｪﾝﾄﾈｯﾄﾜｰｸｻｰﾋﾞｽ
･ｾｷｭﾘﾃｨ(F/W･ｱﾝﾁｳｨﾙｽ･IDS)
･QoS
･管理(CiscoWorksとかOpenViewとか)
･ﾊｲｱﾍﾞｲﾗﾋﾞﾘﾃｨ(冗長性)
･IPﾏﾙﾁｷｬｽﾄ(ﾋﾞﾃﾞｵ会議とか動画配信とか?)
―あまり必要ないかもしれないけどｱﾌﾟﾘｹｰｼｮﾝとｲﾝﾃﾘｼﾞｪﾝﾄ(ryの区別はちゃんと付けられたほうがいいかも

⑤技術目標
･ﾊﾟﾌｫｰﾏﾝｽ(ｽﾙｰﾌﾟｯﾄ向上?)
･ﾊｲｱﾍﾞｲﾗﾋﾞﾘﾃｨ(落ちないようにするとか)
･管理性(人員配置によってはかなり重要[体験済み…orz])
･ｾｷｭﾘﾃｨ
･適応性(ｼｽﾃﾑとして覚えやすいかって事?よくわからん)
･ｽｹｰﾗﾋﾞﾘﾃｨ(まああまり意味ないけど拡張性があること。)
―ｱﾌﾟﾘｹｰｼｮﾝをうまく動かすためにはｲﾝﾃﾘｼﾞｪﾝﾄﾈｯ(ryが必要で、ｲﾝﾃ(ryを実装するためには具体的に技術目標が必要だ、という関係性かな

⑥技術上の制約
･既存の機器(そのまま使わなきゃいけない時。入れ替えられるなら気にｽﾝﾅ)
･帯域幅のｱﾍﾞｲﾗﾋﾞﾘﾃｨ(引ける回線の帯域が足りないとかだと別の技術を使って何とかしなきゃいけない時もあったりして)
･ｱﾌﾟﾘｹｰｼｮﾝの互換性(古いｼｽﾃﾑと共存させたり、古い機器を使わなきゃいけないようなときかな?)
･人員のｽｷﾙ(言わずもがな?)

間違えた問題

5-4
IPv4とIPv6移行段階の共存方法を下から全て選べ
①IPv6にもIPv4にも属さないｱﾄﾞﾚｽ体系を作ること
②IPv6ﾃﾞｰﾀｸﾞﾗﾑをIPv4ﾃﾞｰﾀｸﾞﾗﾑにｶﾌﾟｾﾙ化すること
③IPv6-IPv4間にﾌﾞﾘｯｼﾞ接続を用いること
④ﾌﾟﾛﾄｺﾙ変換を許可するように設定すること
⑤ﾙｰﾀにIPｴﾆｰｷｬｽﾄを許可するように設定すること

5-13
ﾈｯﾄﾜｰｸｾｷｭﾘﾃｨ設計に関する選択肢を全て選べ
①ｾｷｭﾘﾃｨﾘｽｸ分析
②ﾕｰｻﾞ･管理者･技術者への教育
③ﾈｯﾄﾜｰｸ上の資産の把握
④ﾙｰﾃｨﾝｸﾞﾌﾟﾛﾄｺﾙﾒﾄﾘｸｽの把握
⑤ｾｷｭﾘﾃｨ用件の把握

5-18
既存のﾈｯﾄﾜｰｸの特徴を知る為に実行する項目として適切なものを全て選択
①ﾌﾟﾛﾄｺﾙと規格に関する会社の方針
②あるﾍﾞﾝﾀﾞｰとｱﾌﾟﾘｹｰｼｮﾝに関する会社の方針
③ﾈｯﾄﾜｰｸ設計書の参照
④ﾄﾚｰﾆﾝｸﾞされた人材からの聴取
⑤予算

4-12
ある会社の通信ｲﾝﾌﾗの改善と既存ﾈｯﾄﾜｰｸの再ﾃﾞｻﾞｲﾝを実施するに当たって必要となる更なる情報を下記から全て選べ
①ｻｰﾊﾞ機器のOS情報
②認証及びｾｷｭﾘﾃｨに関するﾎﾟﾘｼｰ
③ﾈｯﾄﾜｰｸﾄﾗﾌｨｯｸの特徴･ﾊﾟﾀｰﾝ
④現在のﾈｯﾄﾜｰｸの実装状況
⑤その会社の業界におけるﾏｰｹｯﾄｼｪｱと順位

4-26
ﾈｯﾄﾜｰｸ設計書に必要な項目を以下から選べ
①設計の目的
②既存のﾈｯﾄﾜｰｸに関する項目
③ﾃﾞｰﾀの情報源
④ﾌﾟﾛﾄﾀｲﾌﾟﾈｯﾄﾜｰｸ
⑤技術的な正当性

2-1
5つのﾋﾞﾙが多重光ｹｰﾌﾞﾙのGｲｰｻでｽﾀｰ型接続されている。中央は1号館でﾏﾙﾁﾚｲﾔｽｲｯﾁCat6500を使用している。ﾕｰｻﾞからﾚｽﾎﾟﾝｽが遅くなったり早くなったりして安定しないというｸﾚｰﾑがある。現象は再現性がなく、問題の特定、解決は難しい。この問題の解決に適切なものを1つ選べ
①1号館から各ﾋﾞﾙへの上り回線の冗長化
②各ｻﾌﾞﾈｯﾄにL3ｽｲｯﾁを導入
③1号館から各ﾋﾞﾙへの上り回線をSingleﾓｰﾄﾞに変更
④各ﾋﾞﾙにmultipleVLANを導入

2-16
階層ﾈｯﾄﾜｰｸにおけるﾃﾞｨｽﾄﾘﾋﾞｭｰｼｮﾝﾚｲﾔの機能として適切なものを全て選べ
①ﾒﾃﾞｨｱ変換
②ﾎﾟｰﾄｾｷｭﾘﾃｨ
③高可用性
④VLANのﾙｰﾃｨﾝｸﾞ
⑤ﾚｰﾄ制限
⑥不要ﾊﾟｹｯﾄのﾄﾞﾛｯﾌﾟ


さて皆は出来るかな……ふふふ


ってみんな出来たら立場ねぇなorz

ﾈｯﾄﾜｰｸのｻｰﾋﾞｽﾚﾍﾞﾙの管理

SLA(ServiceLevelAgreement?):ｻｰﾋﾞｽﾚﾍﾞﾙ合意
　ｻｰﾋﾞｽの水準をｴﾝﾄﾞﾕｰｻﾞと契約したﾚﾍﾞﾙに保つ為の合意事項
SLC(ServiceLevelContract):ｻｰﾋﾞｽﾚﾍﾞﾙ契約。複数のSLAを集めて契約の形式にしたもの

SLAの要件
　業務目的をSLAに正しく変換する必要がある
　SLAは次の要件を満たすことが出来る
　　　接続性とﾎｽﾄｱﾌﾟﾘｹｰｼｮﾝが存在する
　　　SLAを詳細なﾚﾍﾞﾙまで定義できる
　　　SLAが守られなかった場合にﾍﾟﾅﾙﾃｨを課す事が出来る
　　　業務ﾚﾍﾞﾙのﾚﾎﾟｰﾄ及び技術的なﾚﾎﾟｰﾄを提出できる
　　　新たな世界的技術を使用した場合に業務目標を達成できるかどうかを検証する
測定基準
　SLAでは、企業管理者(運用者?)がﾈｯﾄﾜｰｸﾘｿｰｽを常に監視･管理する必要がある
　ﾘｿｰｽは様々な測定基準によってﾁｪｯｸされる
　　　ｱﾍﾞｲﾗﾋﾞﾘﾃｨ
　　　ﾚｲﾃﾝｼ
　　　ﾊﾟｹｯﾄ損失
　　　ﾈｯﾄﾜｰｸ遅延変動(ｼﾞｯﾀ)
　SLA違反が生じた場合は即時の通知が必要

ｻｰﾋﾞｽﾚﾍﾞﾙ管理(SLM)
　提供ｻｰﾋﾞｽの接続性とﾊﾟﾌｫｰﾏﾝｽを保障
　ｴﾝﾄﾞﾕｰｻﾞ又は部門と、ﾈｯﾄﾜｰｸﾌﾟﾛﾊﾞｲﾀﾞ又はIT部門との間の契約を含む
　ｴﾝﾄﾞﾂｰｴﾝﾄﾞの管理ではｻｰﾋﾞｽ及び測定基準についていくらかの要素を考慮する
　　　ｸﾗｲｱﾝﾄｱﾌﾟﾘｹｰｼｮﾝの要求を理解する
　　　ﾈｯﾄﾜｰｸﾌﾟﾛﾊﾞｲﾀﾞﾃﾞﾊﾞｲｽのﾃﾞﾊﾞｲｽの機能をチェックする
　　　新しい技術を採用する
　　　全てのOSI層を対象とする

SLM計画の手順
　ﾄﾎﾟﾛｼﾞ
　重要なｻｰﾋﾞｽ
　ｻｰﾋﾞｽの使用方法
　ｻｰﾋﾞｽに対する責任
　受け入れ可能な応答時間

SAA(ServiceAssuranceAgent)
　SAAはCiscoIOSのﾌﾟﾗｯﾄﾌｫｰﾑの1部
　SAAは応答･ｼﾞｯﾀ･ﾊﾟｹｯﾄ損失等様々なﾊﾟﾌｫｰﾏﾝｽ測定基準を対象に出来る
　SAAは次の機能を提供
　　　閾値の違反に対する予防的な通知
　　　柔軟なｽｹｼﾞｭｰﾘﾝｸﾞ
　　　履歴情報の格納
　　　ｸﾗｽ毎のﾄﾗﾌｨｯｸの監視

ﾈｯﾄﾜｰｸの応答性及びｱﾍﾞｲﾗﾋﾞﾘﾃｨを表示する為のｱﾌﾟﾘｹｰｼｮﾝ
　SLMｱﾌﾟﾘｹｰｼｮﾝはSAAを使用することでﾈｯﾄﾜｰｸとｱﾌﾟﾘｹｰｼｮﾝの応答性を測定
　Cisco管理ｱﾌﾟﾘｹｰｼｮﾝ
　　　InternetPerformanceMonitor
　　　ServiceManagementSolution
　　　VPNSolutionCenter
　その他のﾍﾞﾝﾀﾞｰ管理ｱﾌﾟﾘｹｰｼｮﾝ
　　　InfoVista―VistaView
　　　InfoVista―PowerView
　　　Concord―eHealth

ﾈｯﾄﾜｰｸ管理の機能領域(課金管理･性能管理･機密管理)

課金管理
　ﾈｯﾄﾜｰｸﾘｿｰｽの利用率に関するﾃﾞｰﾀを収集する
　ﾃﾞｰﾀを元に使用状況制限を設定する
　ﾈｯﾄﾜｰｸﾘｿｰｽの使用に対してﾕｰｻﾞに課金する
ｱｶｳﾝﾃｨﾝｸﾞﾂｰﾙ
　利用可能な3つの主要ｱｶｳﾝﾃｨﾝｸﾞｵﾌﾟｼｮﾝ
　　　IPｱｶｳﾝﾃｨﾝｸﾞ:IP終端間のﾄﾗﾌｨｯｸの測定用
　　　AAAｱｶｳﾝﾃｨﾝｸﾞ:接続(ﾀﾞｲﾔﾙｲﾝ)の時間測定用
　　　NetFlowｱｶｳﾝﾃｨﾝｸﾞ:ﾌﾛｰごとの詳細ﾄﾗﾌｨｯｸ測定用

IPｱｶｳﾝﾃｨﾝｸﾞ
　発信元IPｱﾄﾞﾚｽ―宛先IPｱﾄﾞﾚｽのﾊﾟｹｯﾄ数･ﾊﾞｲﾄ数を測定
　ｱｶｳﾝﾃｨﾝｸﾞ情報は、一旦ﾙｰﾀのﾒﾓﾘに保管される(ｻｰﾊﾞからのﾎﾟｰﾘﾝｸﾞで収集)
　CiscoIOSのｺﾏﾝﾄﾞ又はSNMPを使用してｱｶｳﾝﾃｨﾝｸﾞﾃﾞｰﾀを収集できる
　付加機能でMACｱﾄﾞﾚｽ･IP優勢順位･ACL違反に基づいたｱｶｳﾝﾃｨﾝｸﾞをｻﾎﾟｰﾄ

AAAｱｶｳﾝﾃｨﾝｸﾞ
　重要な機能:ｱｶｳﾝﾃｨﾝｸﾞ
　認証される権限付与ｲﾍﾞﾝﾄに関する情報の収集に使用される
　ﾀﾞｲﾔﾙｱｯﾌﾟ方式のﾈｯﾄﾜｰｷﾝｸﾞでの接続時間の測定に使用される
　ﾈｯﾄﾜｰｸﾃﾞﾊﾞｲｽにより管理ｻｰﾊﾞへ送られる
※RADIUS･TACACS+ｻｰﾊﾞ等の外部ｻｰﾊﾞに保管される???

NetFlowｱｶｳﾝﾃｨﾝｸﾞ
　3層になったｱｰｷﾃｸﾁｬを使用
　　　NetFlow対応ﾃﾞﾊﾞｲｽ
　　　NetFlow収集装置
　　　ｱｶｳﾝﾃｨﾝｸﾞ･課金ｱﾌﾟﾘｹｰｼｮﾝ
　包括的な課金ｵﾌﾟｼｮﾝを備える
　　　日時
　　　ｱﾌﾟﾘｹｰｼｮﾝ
　　　距離ﾍﾞｰｽ
　　　QoS及びCoS
　　　ﾄﾗﾝｼﾞｯﾄ又はﾋﾟｱ
　　　転送済みﾃﾞｰﾀ


性能管理
　ﾃﾞｰﾀﾈｯﾄﾜｰｸがｱｸｾｽ出来、出来るだけ輻輳しないようにすること
　ﾈｯﾄﾜｰｸの過密とｱｸｾｽ不能状況を軽減
　一貫したﾚﾍﾞﾙでﾈｯﾄﾜｰｸﾕｰｻﾞｰにｻｰﾋﾞｽを提供する
　ﾊﾟﾌｫｰﾏﾝｽ問題を切り離し、解決する為に利用率のﾄﾚﾝﾄﾞを判別
　ｷｬﾊﾟｼﾃｨに密接に関連

ﾊﾟﾌｫｰﾏﾝｽ管理のｱｸﾃｨﾋﾞﾃｨ
　ｻｰﾋﾞｽﾚﾍﾞﾙの管理
　ﾈｯﾄﾜｰｸ及びｱﾌﾟﾘｹｰｼｮﾝのWhat-if分析
　ﾍﾞｰｽﾗｲﾝ設定とﾄﾚﾝﾄﾞ分析
　例外管理
　Qos管理

ｷｬﾊﾟｼﾃｨ情報の報告
　ﾈｯﾄﾜｰｷﾝｸﾞ要件の判別
　ﾌﾟﾛｾｽの定義
　ｷｬﾊﾟｼﾃｨ領域の定義(ﾈｯﾄﾜｰｸの範囲)
　ｷｬﾊﾟｼﾃｨ変数の定義(CPU･ﾒﾓﾘ･ﾘﾝｸの利用率等)
　データ解析

課題
　待ち時間の遅延の特定
　遅延の原因の特定
　→ツールを使う

性能管理のｿﾘｭｰｼｮﾝ
　Ping:ﾃﾞﾊﾞｲｽの到達可能性と応答を返す
　　　 ﾈｯﾄﾜｰｸの障害が生じた箇所を詳細に特定できない
　RMON:ﾈｯﾄﾜｰｸｾｸﾞﾒﾝﾄのﾊﾟﾌｫｰﾏﾝｽを監視する
　　　 全体のﾊﾟﾌｫｰﾏﾝｽを調べるには多数のﾌﾟﾛｰﾌﾞが必要
　NetFlow:Cisco製のﾃﾞﾊﾞｲｽからの詳細なIPﾄﾗﾌｨｯｸ統計情報を提供

ﾊﾟﾌｫｰﾏﾝｽﾂｰﾙ(IPM･SAA)
　ｴﾝﾄﾞﾂｰｴﾝﾄﾞ及びﾎｲｯﾌﾟﾊﾞｲﾎｲｯﾌﾟで待ち時間を測定
　統合ﾄﾗﾌｨｯｸ(TCP接続･DNS･DHCP･音声･実際使用されるｱﾌﾟﾘｹｰｼｮﾝのﾃﾞｰﾀ)を使用して待ち時間を測定する


機密管理
　ｾｷｭﾘﾃｨ(認証と暗号化)･ｽｹｰﾗﾋﾞﾘﾃｨ･管理性･ｱｶｳﾝﾃｨﾝｸﾞを用意する必要がある
　ﾙｰﾀとｽｲｯﾁにより管理するﾌﾟﾛﾄｺﾙが異なる場合がある(Telnet･SNMP･HTTP･RSH/RCMD･SSH)
　必要な管理ﾌﾟﾛﾄｺﾙは一つなので、他のﾌﾟﾛﾄｺﾙは無効にしておく
　全てのﾈｯﾄﾜｰｸﾃﾞﾊﾞｲｽで同じ管理ｱﾌﾟﾛｰﾁをする必要がある
　Telnet:ﾊﾟｽﾜｰﾄﾞがｸﾘｱﾃｷｽﾄで送信される･ﾊﾟｽﾜｰﾄﾞが1つしかない
　→AAAを使ってﾕｰｻﾞ名とPassの管理をする
　ﾙｰﾀ又はｽｲｯﾁ間でRADIUS･TACACS+を使用し、AAAｻｰﾊﾞを使用する

ﾈｯﾄﾜｰｸ管理用のﾌﾟﾛﾄｺﾙと機能の確認

ﾈｯﾄﾜｰｸ管理ｱｰｷﾃｸﾁｬ
　ﾈｯﾄﾜｰｸ管理ｼｽﾃﾑ
　ﾈｯﾄﾜｰｸ管理ﾌﾟﾛﾄｺﾙ
　管理対象ﾃﾞﾊﾞｲｽ
　管理ｴｰｼﾞｪﾝﾄ
　管理情報

ﾌﾟﾛﾄｺﾙと標準
　SNMP
　MIB:管理情報ﾍﾞｰｽ
　RMON:ﾘﾓｰﾄﾓﾆﾀﾘﾝｸﾞ

SNMPﾒｯｾｰｼﾞﾀｲﾌﾟ
ﾏ |→→→get request(特定のMIB変数値を取得)→→→→|管理
ﾈ |→get next reqest(次に発行されるMIB変数を取得)→|対象
ｰ |→→→→→set request(MIB変数値を修正)→→→→→|装置
ｼﾞ|←←get response(要求された変数の値を含む)←←←|ｴｰｼﾞｪﾝﾄ
ｬ |←←←←←trap(ｱﾗｰﾑ状況を自発的に送信)←←←←←|(MIB)

SNMPv2c:RFC1901
　　　　InformRequest,GetBulkﾒｯｾｰｼﾞﾀｲﾌﾟの追加
　　　　CiscoIOS11.3以降で対応
SNMPv3:RFC2571～2575
　　　 認証とﾌﾟﾗｲﾊﾞｼｰ
　　　 認可とｱｸｾｽ制御
　　　 ﾕｰｻﾞ名とｷｰの管理
　　　 SNMP操作によってﾘﾓｰﾄに構成可能
　　　 CiscoIOS12.0以降でﾘﾘｰｽ

MIB
　管理対象ｵﾌﾞｼﾞｪｸﾄのｺﾚｸｼｮﾝ
　各ｵﾌﾞｼﾞｪｸﾄが固有の識別子を持つ
　ｵﾌﾞｼﾞｪｸﾄはﾂﾘｰ内にｸﾞﾙｰﾌﾟ化される
　標準MIB(ﾕﾆﾊﾞｰｻﾙ変数):RFCに定義されたﾏﾙﾁﾍﾞﾝﾀﾞなMIB
　　　Interface･buffers･memory･standard protocols等
　ﾌﾟﾗｲﾍﾞｰﾄMIB:ﾍﾞﾝﾀﾞ固有のMIB
　　　small/medium/large/huge buffers
　　　primary/secondary memory
　　　proprietary protocols　等(Cisco)

MIB-Ⅱ
　RFC1213で定義
　MIB-Ⅰを拡張
　複数のﾌﾟﾛﾄｺﾙをｻﾎﾟｰﾄ
　問題:依然としてﾃﾞﾊﾞｲｽ中心･ﾎﾟｰﾘﾝｸﾞﾍﾞｰｽ

CiscoMIB
ｻﾌﾞﾂﾘｰ:local:CiscoIOS10.2･SNMPv1以前に定義されたもの
　　　 temporary:IP以外のﾌﾟﾛﾄｺﾙを使用するｵﾌﾞｼﾞｪｸﾄ
　　　 ciscoMgmt:CiscoIOS10.2+･SNMPv2以後に定義されたもの

RMON1
　LANﾄﾗﾌｨｯｸの予防的な監視をｻﾎﾟｰﾄする目的で開発された
　　　ﾈｯﾄﾜｰｸ障害診断
　　　計画
　　　ﾊﾟﾌｫｰﾏﾝｽ調整
　MAC層ﾃﾞｰﾀを扱う
　　　ﾘﾓｰﾄLANｾｸﾞﾒﾝﾄの集計されたLANﾄﾗﾌｨｯｸだけを監視
　　　ﾄﾗﾌｨｯｸの統計値と分析
　ｴｰｼﾞｪﾝﾄの実装
　　　ﾙｰﾀ･ｽｲｯﾁ･ﾊﾌﾞ･ｻｰﾊﾞ･ﾎｽﾄ･専用ﾌﾟﾛｰﾌﾞ
　ｸﾞﾙｰﾌﾟ(RFC-1757/1513)
　　　1 statistics:ﾘｱﾙﾀｲﾑな現在の統計値
　　　2 history:定期的な統計値
　　　3 alarm:事前設定した閾値の監視
　　　4 host:各ﾎｽﾄの統計値を追跡
　　　5 hostTopN:上位N個のｱｸﾃｨﾌﾞなﾎｽﾄ
　　　6 matrix:A<>B間の会話の統計値
　　　7 filters:ﾊﾟｹｯﾄ構造と内容の一致
　　　8 packetCapture:後の分析用に収集
　　　9 events:事前設定された条件に反応
　　 10 tokenRing:ﾄｰｸﾝﾘﾝｸﾞ-RMON拡張
　ﾃﾞｰﾀﾘﾝｸ層と物理層の問題のみを取り扱う

RMON2
　RMON1の拡張(L3～L7)
　9つのｸﾞﾙｰﾌﾟを追加
　任意のﾃﾞﾊﾞｲｽ･ｻﾌﾞﾈｯﾄの任意のﾌﾟﾛﾄｺﾙﾄﾗﾌｨｯｸを監視
　ﾈｯﾄﾜｰｸ会話のｴﾝﾄﾞﾂｰｴﾝﾄﾞﾋﾞｭｰ

CDP
　CiscoIOS10.3以降
　要約情報
　　　ﾃﾞﾊﾞｲｽID:ﾎｽﾄ名
　　　ｱﾄﾞﾚｽﾘｽﾄ:IP等
　　　ﾎﾟｰﾄID:ﾎﾟｰﾄ番号
　　　能力ﾘｽﾄ:ﾙｰﾀか、ｽｲｯﾁか等
　　　ﾌﾟﾗｯﾄﾌｫｰﾑ:ﾃﾞﾊﾞｲｽの機種名
　　　ﾛｰｶﾙｲﾝﾀｰﾌｪｰｽ:ｲﾝﾀｰﾌｪｰｽ番号
　　　ﾎｰﾙﾄﾞﾀｲﾑ:60秒毎に保管するｷｬｯｼｭを破棄するまでの時間(180秒)

NetFlow
　NetFlowは測定技術
　NetFlowはｼｽｺのﾃﾞﾊﾞｲｽを通過するﾌﾛｰを測定
　ﾌﾛｰとは特定の送信元と宛先間の一方向のﾊﾟｹｯﾄｼｰｹﾝｽ
　NetFlowﾃﾞｰﾀの使用目的
　　　ｱｶｳﾝﾃｨﾝｸﾞと課金
　　　ﾈｯﾄﾜｰｸの計画
　　　ﾕｰｻﾞとｱﾌﾟﾘｹｰｼｮﾝの監視

NetFlowの情報収集
　送信元･送信先ｲﾝﾀｰﾌｪｰｽ
　送信元･送信先IPｱﾄﾞﾚｽ
　IPｱﾌﾟﾘｹｰｼｮﾝ
　BGP AS
　1日の時間帯
　ﾃﾞｰﾀ量
　QoS
RMONの情報収集
　SNMPによってｱｸｾｽ可能なMIB
　1日の特定の時間帯を使用
　制限されたｲﾝﾀｰﾌｪｰｽのｻﾎﾟｰﾄ
　多数のｲﾝﾀｰﾌｪｰｽにｽｹｰﾙしない
　ﾒﾓﾘﾃｰﾌﾞﾙの制限されたｽｹｰﾗﾋﾞﾘﾃｨ

SYSLOG
　ﾃﾞﾊﾞｲｽはSYSLOGﾒｯｾｰｼﾞを生成する
　SYSLOGﾒｯｾｰｼﾞにはﾚﾍﾞﾙとﾌｧｼﾘﾃｨが含まれる
　SYSLOGﾚﾍﾞﾙ
　　　emergency(0)
　　　alert　(1)
　　　critical(2)
　　　error(3)
　　　warning(4)
　　　notice(5)
　　　informational(6)
　　　debugging(7)
　ﾃﾞﾌｫﾙﾄで0～5までのﾒｯｾｰｼﾞをﾀｰﾐﾅﾙに送信する
　一般的なSYSLOGﾌｧｼﾘﾃｨ
　　　IP
　　　OSPF
　　　SYS(ｵﾍﾟﾚｰﾃｨﾝｸﾞｼｽﾃﾑ)
　　　SEC(IPｾｷｭﾘﾃｨ)
　　　RSP(RouteSwitchProcessor)
　　　IF(ｲﾝﾀｰﾌｪｰｽ)

音声ﾄﾗﾌｨｯｸ処理の概念によるｷｬﾊﾟｼﾃｨの計画

ｵﾝﾈｯﾄｺｰﾘﾝｸﾞとｵﾌﾈｯﾄｺｰﾘﾝｸﾞ
　ｵﾝﾈｯﾄｺｰﾘﾝｸﾞとは専用線やFRの様なﾌﾟﾗｲﾍﾞｰﾄなﾈｯﾄﾜｰｸを使用した通話方式
　ｵﾌﾈｯﾄｺｰﾘﾝｸﾞとは公衆回線網を利用した通話方式
　　ﾌﾟﾗｲﾍﾞｰﾄﾀｲﾗｲﾝが輻輳している
　　発信側がｵﾝﾈｯﾄで到達不能
　　ﾕｰｻﾞがｵﾌﾈｯﾄ延長を手動で選択している
　ｵﾝﾈｯﾄは通常固定料金、ｵﾌﾈｯﾄは通常従量課金なのでｵﾌﾈｯﾄｺｰﾙをできるだけ少なくすることが重要

GoS
GoSの測定：ｱｰﾗﾝ･CCS･同時会話という3つのﾀｲﾌﾟがある
Pxxﾌﾞﾛｯｷﾝｸﾞ係数の形式で計算できる(xxは%が入る)
　計算式－ｱｰﾗﾝ:1時間の電話会話
　　　　　　　1時間あたりのコール数*平均コール時間/60
　　　　　CCS(CentumCallSecond)＝ｱｰﾗﾝ*36
　　　　　　
　ｻｰﾋﾞｽｸﾞﾚｰﾄﾞは以下の方法で測定
　　・ｺｰﾙﾚｯｸﾞの使用
　　・ﾋﾞｼﾞﾈｽ時間における同時会話

ｱｰﾗﾝ表:ﾄﾗﾌｨｯｸ･回線数･ｻｰﾋﾞｽｸﾞﾚｰﾄﾞが以下のﾄﾗﾌｨｯｸﾓﾃﾞﾙとして示される
　ｱｰﾗﾝB:最も一般的なﾄﾗﾌｨｯｸﾓﾃﾞﾙ･最も通話が混む時間帯におけるﾄﾗﾌｨｯｸ値(ｱｰﾗﾝ単位)が分かっているときに必要な回線数を計算する為に使用。ﾌﾞﾛｯｸされているﾓﾃﾞﾙが即座にｸﾘｱされる事が前提

　拡張ｱｰﾗﾝB:ﾌﾞﾛｯｸされている発信者が即座に再ｺｰﾙすることによって追加ﾄﾗﾌｨｯｸの負荷が考慮される
　ｱｰﾗﾝC:ﾌﾞﾛｯｸされているｺｰﾙがｷｭｰｲﾝｸﾞされることを前提にする

――――――――――――――――――――――――――――――――――――

実はここでかなりの無駄な時間を費やした。ﾃｷｽﾄの内容がまったく理解できないのだ。書かれているとおりに計算してもどうも同じ数値にならない。ｲﾝｽﾄﾗｸﾀｰを呼んで計算するも、どうもおかしい。
そもそもﾃｷｽﾄの最初にCCS＝ｱｰﾗﾝ/36と書いてある(上は修正済み)のに後のページでは｢4.462アーランは約160CCS(4.462*36)です｣となってる。掛けるのか割るのかどっちなんじゃぁぁぁぁぁぁ
続いての問題
"4.462ｱｰﾗﾝとすると約160CCS(4.462*36)です。会社内に20人のﾕｰｻﾞがいる場合、全てのﾕｰｻﾞが1時間に8分間話すことができる"
上記の問題は"1時間あたりのコールが20で平均8分"と言い換えることが出来る。そこでｱｰﾗﾝを求める式(1時間あたりのコール数*平均コール時間/60)に代入してみる。
20*8/60=2.666ｱｰﾗﾝ
ｱﾚ?
4.462ｱｰﾗﾝだったんじゃないのーーーーーー
考えに考えた末に下のようなメールを出してみた


1.テキストVol.3、8-136で、｢CSSはアーランの36分の1です｣と書いてありますが、8-138では｢4.462アーランは約160CCS(4.462*36)です｣と36倍しているようなのですがどちらが正しいのでしょうか？

2.8-138で、｢会社に20人のユーザがいる場合、全てのユーザが1時間に8分話すことが出来る｣というのは"1時間あたりのコールが20で平均8分"というのと同義だと思うのですが、それでhttp://www.erlang.com/whatis.htmlのページ通りに計算すると、
Minutes of traffic in the hour = number of calls x duration
Minutes of traffic in the hour = 20 x 8
Minutes of traffic in the hour = 160
Hours of traffic in the hour = 160 / 60
Hours of traffic in the hour = 2.666666～
Traffic figure = 2.6 Erlangs
となり、そもそも4.462で計算されていたアーランが変わってしまってるように思うのですが、そもそも160CCSというのは｢コールの平均時間(秒単位)を掛けて、その結果を100で割ります｣とあるならば一度100を掛けて秒単位に直してやらなければユーザが"何分"話せるか、という単位にならないのではないのでしょうか。
実際、160*100/20=800秒≒13.33分で出た13.33分を使って計算すると、20*13.33/60=4.443となり、最初に定義されていたアーランの値に近い数字が出ると思うのですが。


さてどう帰ってくるか。

音声技術の要件の特定

固定遅延に関する検討事項
伝搬遅延:6μs/km→ｿﾘｭｰｼｮﾝなし(衛星回線使用時以外ほぼ無視できる)
連続化遅延:ﾌﾚｰﾑ長/ﾋﾞｯﾄﾚｰﾄ→高速なﾘﾝｸ･小さいﾊﾟｹｯﾄ
処理遅延:ｺｰﾃﾞｯｸに依存→ﾊｰﾄﾞｳｪｱDSP･符号化ｱﾙｺﾞﾘｽﾞﾑ

可変遅延に関する検討事項
ｷｭｰｲﾝｸﾞ遅延→ﾘﾝｸの分割とｲﾝﾀｰﾘｰﾌﾞ
ﾃﾞｼﾞｯﾀﾊﾞｯﾌｧ(受信側のみ)→一定の遅延、輻輳のないﾈｯﾄﾜｰｸ
可変ﾊﾟｹｯﾄｻｲｽﾞ→ﾘﾝｸの分割とｲﾝﾀｰﾘｰﾌﾞ

帯域幅のｱﾍﾞｲﾗﾋﾞﾘﾃｨ
　効率的な音声符号化及び圧縮ﾒｶﾆｽﾞﾑを使用する
　cRTP(compressedRTP)を使用しIPﾍｯﾀﾞｰを圧縮
　VAD(VoiceActivityDetection)を使用して無音のﾊﾟｹｯﾄを圧縮する

音声帯域幅要件


QoSﾈｯﾄﾜｰｷﾝｸﾞﾒｶﾆｽﾞﾑ
　帯域削減
　帯域予約
　QoS分類
　輻輳管理
　輻輳回避

輻輳管理QoSﾒｶﾆｽﾞﾑ
IP RTP優先順位→音声はRTPﾎﾟｰﾄ番号によって識別され、ﾌﾟﾗｲｵﾘﾃｨｰｷｭｰに分類される
PQ→4つのﾄﾗﾌｨｯｸｷｭｰに基づいた優先順位
CQ→ﾗｳﾝﾄﾞﾛﾋﾞﾝ方式で順番に処理。最大16のｷｭｰ
WFQ→重み(IPﾌﾟﾚｼﾃﾞﾝｽ)に基づいてｷｭｰの帯域幅が均等に分割される
CBWFQ→定義されているｸﾗｽと重みに基づいて帯域幅が保障されるWFQ。完全優先ｷｭｰは使用できない
LLQ(PQCBWFQ)→定義されているｸﾗｽと重みに基づいて帯域幅が保障されるWFQ。完全優先ｷｭｰが使用出来る－PQとCBWFQを同時に使える
ｃｆ.
ﾃﾞｰﾀ･音声→分類→音声→PQ→1
　　　　　　　　　↓
　　　　　　　　ﾃﾞｰﾀ→CBWFQ→2

VoFR・VoATM

VoFR
　既存のPBXを相互接続するための技術
　FR網上に展開
　64kbps～512kbpsのﾘﾝｸ上で導入される
　高い音声品質を維持する為には様々なQoSﾒｶﾆｽﾞﾑが必要
　ﾄﾗﾌｨｯｸｽﾄﾘｰﾑがCIRに厳密に準拠する必要がある
静的FRF.11ﾄﾗﾝｸ(ﾀｲﾗｲﾝﾄﾗﾝｸ)
　PBXの相互接続用
　ﾀｲﾗｲﾝと似ている
　PBXによって全ての音声交換が行われる
動的交換VoFRｺｰﾙ
　発信された電話番号を元にﾙｰﾀがｺｰﾙの処理･ﾙｰﾃｨﾝｸﾞを行う
　ﾊﾟｽ上の全てのVoFRﾙｰﾀにﾀﾞｲﾔﾙ計画情報がある
　=ﾙｰﾄ間全てのﾙｰﾀに音声対応ﾙｰﾀが必要
ﾌﾙﾒｯｼｭﾄﾎﾟﾛｼﾞ:ｺｽﾄ高･ﾎｯﾌﾟ数が最小限･遅延が最小限･高い音声品質
ﾊﾌﾞｱﾝﾄﾞｽﾎﾟｰｸﾄﾎﾟﾛｼﾞ:ｺｽﾄ低･ﾎｯﾌﾟ数の増加･遅延の増加･音声品質の低下

VoATM
　ｺﾈｸｼｮﾝ型
　小さい固定ｻｲｽﾞ(53ﾊﾞｲﾄ)のｾﾙを使用
　LAN及びWANﾄﾗﾌｨｯｸに適用されている
　ATM仮想回線はPSTN回線をｴﾐｭﾚｰﾄする
　遅延と遅延変動(ｼﾞｯﾀ)が最小限
　様々なｻｰﾋﾞｽｸﾗｽをｻﾎﾟｰﾄ
　　―ﾘｱﾙﾀｲﾑｻｰﾋﾞｽ(音声転送用)
　　　VBR(可変ﾋﾞｯﾄﾚｰﾄ)
　　　CBR(固定ﾋﾞｯﾄﾚｰﾄ)
　　―非ﾘｱﾙﾀｲﾑｻｰﾋﾞｽ(ﾃﾞｰﾀ転送用)
　　　UBR(未指定ﾋﾞｯﾄﾚｰﾄ)
　　　ABR(使用可能ﾋﾞｯﾄﾚｰﾄ)

ATMｱﾀﾞﾌﾟﾃｰｼｮﾝﾀｲﾌﾟ
　AAL5:同一仮想回線上で個別の音声及びﾃﾞｰﾀ仮想回線又は混合音声及びﾃﾞｰﾀﾄﾗﾌｨｯｸを使用
　AAL2:ATMﾌｫｰﾗﾑによって標準化されたVoATM
　　　 音声とﾃﾞｰﾀに個別の仮想回線を使用
　　　 様々なﾍﾟｲﾛｰﾄﾞを使用可
　　　 音声圧縮と無音圧縮をｻﾎﾟｰﾄ
　　　 音声に最適
　AAL1:2つのﾎﾟｲﾝﾄ間でﾄﾗﾝｷﾝｸﾞを行う
　　　 CBRｻｰﾋﾞｽとともに使用される
　　　 帯域幅が節約されない
　　　 音声には適してない

音声に関する問題/VoIP制御及び転送ﾌﾟﾛﾄｺﾙ

遅延
　ﾕｰｻﾞは即座に応答が帰ってくる対話式の音声を期待している
　片方向遅延は150ms以下に抑える必要がある
　遅延のﾀｲﾌﾟ
　　固定･処理遅延:ｺｰﾀﾞ遅延。ｱﾅﾛｸﾞ>ﾃﾞｼﾞﾀﾙ変換圧縮時の処理の遅延
　　　　･連続化遅延:ﾃﾞｰﾀﾌﾚｰﾑの回線送信時におきるﾘﾝｸ速度による遅延
　　　　･伝搬遅延:回線の長さによる遅延
　　可変･ｷｭｰｲﾝｸﾞ遅延:回線速度とｷｭｰの状態によって変わる
　　　　･ﾃﾞｼﾞｯﾀ遅延:一定でないﾀｲﾐﾝｸﾞで届く音声ﾊﾟｹｯﾄを一定にする為に使用するﾃﾞｼﾞｯﾀﾊﾞｯﾌｧに起因する遅延

ｼﾞｯﾀ
　受信ﾊﾟｹｯﾄの遅延変動―ﾈｯﾄﾜｰｸの輻輳･不適切なｷｭｰｲﾝｸﾞ･構成ｴﾗｰが主原因
　ﾃﾞｼﾞｯﾀﾊﾞｯﾌｧ(再生遅延ﾊﾞｯﾌｧ)を使用して受信側の音声ｹﾞｰﾄｳｪｲで補正する
　輻輳が起きないﾈｯﾄﾜｰｸでは考慮しない(遅延の原因となる為)

ﾊﾟｹｯﾄﾛｽ
　音声のｸﾘｯﾋﾟﾝｸﾞやｽｷｯﾌﾟの原因となる
　ﾊﾟｹｯﾄﾛｽの発生原因
　　―ﾘﾝｸの輻輳
　　　不適切なﾈｯﾄﾜｰｸQoS
　　　不適当なﾊﾟｹｯﾄﾊﾞｯﾌｧ管理
　　　ﾙｰﾃｨﾝｸﾞの問題等
　DSPは補間機能を使用して最大30msの紛失音声を修正可能
　CiscoVoIPでは20msｻﾝﾌﾟﾙの音声ﾍﾟｲﾛｰﾄﾞが利用される
　ﾊﾟｹｯﾄﾛｽが1ﾊﾟｹｯﾄのみであれば、音声品質を低下させずに修正可能

ｴｺｰ
　20msを越えると会話を妨げることがある
　ｴｺｰの原因:ｱﾅﾛｸﾞ電話･ﾊｲﾌﾞﾘｯﾄﾞ変換機
　解決方法:ｴｺｰｷｬﾝｾﾚｰｼｮﾝ･信号の減衰


音声の符号化と圧縮･ｺｰﾃﾞｯｸMOS
PCM　　　　　64kbps　　　　　4.1(最高値)
ADPCM　　　　16/24/32/40kbps 3.85以下
LD-CELP　　　16kbps　　　　　3.61
CS-ACELP　　 8kbps　　　　　 3.92
ACELP/MPMLQ　6.5/5.3kbps　　 3.9/3.65

VoIP制御及び転送ﾌﾟﾛﾄｺﾙ
制御ｼｸﾞﾅﾘﾝｸﾞ:到達する順序が重要なので、信頼性の高いTCP/IP通信を利用
音声会話転送:到達する速度が重要なので、効率のよいUDP/IP通信を利用
TCP/IP制御系
　H.225ｺｰﾙｼｸﾞﾅﾘﾝｸﾞﾁｬﾈﾙ(Q.931):ﾋﾟｱ間の接続を確立
　H.245制御ﾁｬﾈﾙ:機能交換･論理ﾁｬﾈﾙの開閉･優先順位要求･ﾌﾛｰ制御ﾒｯｾｰｼﾞ等
UDP/IP制御系
　RASｼｸﾞﾅﾘﾝｸﾞ:登録･許可･帯域幅変更･ｽﾃｰﾀｽ･ｹﾞｰﾄｳｪｲとｹﾞｰﾄｷｰﾊﾟｰの分離手順を実行
　RTCP:ﾊﾟｹｯﾄｶｳﾝﾄ･ﾊﾟｹｯﾄﾛｽ･内部到着ｼﾞｯﾀ等をﾓﾆﾀﾘﾝｸﾞ
音声会話ﾃﾞｰﾀ
　RTP(Real-time Transport Protocol):ﾊﾟｹｯﾄｼｰｹﾝｽ･ﾀｲﾑｽﾀﾝﾌﾟ

音声ｱｰｷﾃｸﾁｬの統合

VoIP
　PSTNは音声信号伝達では効率的
　PTSNではﾃﾞｰﾀ･音声･映像を統合することは難しい
　ﾘﾝｸ削減によるｺｽﾄ削減

回線交換網
TDM(Time-Division Multiplexing)

H.323
　IPﾍﾞｰｽのﾈｯﾄﾜｰｸを介したﾊﾟｹｯﾄﾍﾞｰｽの映像･音声･ﾃﾞｰﾀ通信を規定するITU-T規格
　　音声と映像の圧縮ｺｰﾃﾞｯｸ規格
　　ｾｯｼｮﾝ設定･ﾓﾆﾀﾘﾝｸﾞ･終端
　　その他一連の規格に関連している
　　　－H.225(Q.931):ｺｰﾙｼｸﾞﾅﾘﾝｸﾞ
　　　－H.245:機能ﾈｺﾞｼｴｰｼｮﾝとﾒﾃﾞｨｱｽﾄﾘｰﾑ管理
　利点
　　H.323に準拠することにより、相互運用を実現できる
　　ﾊｰﾄﾞを選ばない
　　ﾈｯﾄﾜｰｸの独立性
　　帯域幅管理ｻﾎﾟｰﾄ
　　ﾏﾙﾁｷｬｽﾄｻﾎﾟｰﾄ
　　さまざまな機能を持つ端末との通信における柔軟性
　ｺﾝﾎﾟｰﾈﾝﾄ
　　端末(NetMeetingｲﾝｽﾄｰﾙ済みPC･IPPone)
　　ｹﾞｰﾄｳｪｲ(音声対応のﾙｰﾀとｽｲｯﾁ)
　　ｹﾞｰﾄｷｰﾊﾟｰ(ｻｰﾄﾞﾊﾟｰﾃｨｰのｿﾌﾄかCiscoIOSﾙｰﾀ)
　　ﾏﾙﾁﾎﾟｲﾝﾄ制御ﾕﾆｯﾄ(ﾏﾙﾁﾎﾟｲﾝﾄ会議ﾃﾞﾊﾞｲｽ)

IPﾃﾚﾌｫﾆｰ
　PSTNより経済的なIPﾈｯﾄﾜｰｸを介した音声通話
　ﾊﾟｹｯﾄ交換
　IPﾍﾞｰｽのPBX機能の提供
　4つの個別ｺﾝﾎﾟｰﾈﾝﾄを備えたｱｰｷﾃｸﾁｬ
　　　ｲﾝﾌﾗｽﾄﾗｸﾁｬ
　　　ｺｰﾙ処理
　　　ｱﾌﾟﾘｹｰｼｮﾝ
　　　ｸﾗｲｱﾝﾄ

IPﾃﾚﾌｫﾆｰの設計上の目的
　ｴﾝﾄﾞﾂｰｴﾝﾄﾞIPﾃﾚﾌｫﾆｰ
　音声品質
　電話ｺｰﾙのﾙｰﾃｨﾝｸﾞにﾊﾟﾌﾞﾘｯｸｲﾝﾀｰﾈｯﾄ･ﾌﾟﾗｲﾍﾞｰﾄIPﾈｯﾄﾜｰｸを使用することにより長距離のｺｽﾄを下げる
　ﾈｯﾄﾜｰｸ(WAN)機能を効率的に使用する
　ｲﾝﾄﾗﾈｯﾄは企業ｻｲﾄ間のﾌﾟﾗｲﾏﾘ音声ﾊﾟｽとして機能する
　PSTNは企業ｻｲﾄ間のｾｶﾝﾀﾞﾘ音声ﾊﾟｽとして機能
　所有権の合計ｺｽﾄを安くし、柔軟性を高める
　新しいｱﾌﾟﾘｹｰｼｮﾝを使用できるようにする
　ﾕｰｻﾞの生産性を上げる
　ﾃﾞｰﾀ網と電話網を統合することによって運用ｺｽﾄと機器ｺｽﾄを削減

単一ｻｲﾄIPﾃﾚﾌｫﾆｰ設計
　IPPhone･音声ﾒｰﾙｻｰﾊﾞ･CiscoCallManager･音声機能を持つﾙｰﾀで構築可能
　(最小構成)
中央集中型IPﾃﾚﾌｫﾆｰ設計
　上記にﾘﾓｰﾄﾈｯﾄﾜｰｸを参加させる
　WANで接続していればIPPhoneを追加するだけでﾘﾓｰﾄﾎｽﾄは以前の構成で使用可能(CCMが必要ない)
ｲﾝﾀｰﾈｯﾄIPﾃﾚﾌｫﾆｰ設計
　全てのｻｲﾄでCCMが必要(ｲﾝﾀｰﾈｯﾄVPN使ってる場合は???)
　PSTNへの接続をしなければﾙｰﾀは音声対応のものでなくてもよい
　回線ｺｽﾄは安くなるが遅延が問題となる
　ｻｰﾋﾞｽレベル保障契約をすることが必要

音声対応ﾙｰﾀ
　音声対応ﾙｰﾀの物理ﾎﾟｰﾄ
　外線や電話機などに接続し、呼を確立する為に必要
　外線接続:PSTNﾈｯﾄﾜｰｸ/ISDN PRI/ISDN BRI
　PBX接続:PBX/ISDN PRI/ISDN BRI/T1-CASｼｸﾞﾅﾘﾝｸﾞ
　ｱﾅﾛｸﾞ電話:FXS

ﾀﾞｲｱﾙﾋﾟｱ
　物理音声ﾎﾟｰﾄに関連付けられた論理ﾋﾟｱ
　宛先電話番号を物理音声ﾎﾟｰﾄ(POTS)･IP(VoIP)･FR(VoFR)･ATM(VoATM)ｱﾄﾞﾚｽに関連付ける
　接続用ｵﾍﾟﾚｰｼｮﾝﾊﾟﾗﾒｰﾀを記述する
　着信ｺｰﾙと発信ｺｰﾙに関連付けられる
　POTSﾀﾞｲｱﾙﾋﾟｱ:従来の電話網接続の特性を定義
　VoIPﾀﾞｲｱﾙﾋﾟｱ:VoIPｺｰﾙをIPｸﾗｳﾄﾞ内の宛先に転送する方法を定義
　VoFRﾀﾞｲｱﾙﾋﾟｱ:ｺｰﾙの出口ﾙｰﾀにあるDLCIにﾏｯﾋﾟﾝｸﾞする
　VoATMﾀﾞｲｱﾙﾋﾟｱ:ｺｰﾙの出口ﾙｰﾀにあるATMの仮想回線にﾏｯﾋﾟﾝｸﾞする

ﾀﾞｲﾔﾙﾋﾟｱとｺｰﾙﾚｯｸﾞの関係
　よくわからんのだけど各ﾀﾞｲｱﾙﾋﾟｱをｺｰﾙﾚｯｸﾞと称するって事か?
模擬問題に出ないでくれればこのままそっとしておこう……